[native] Investigate further CoreCLR host size reductions
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- android, cpp
- Domain
- build-system, mobile, performance
Research direction
Prepare the ARM64 net-android.release target and record linked and stripped sizes for libmonodroid.so. Evaluate the behavior-neutral linker and compiler changes independently, then replace the DSO in an API-24 sample APK and cold-start it on an ARM64 emulator. Done means required JNI exports and managed startup remain working, with size, startup, resource, link-time, and diagnostic results recorded across supported ABIs.
Written by the indexing model from the issue text.
Description
Follow-up to #12533.
Android framework version
net11.0-android (Preview)
Affected platform version
Current dotnet/android CoreCLR native runtime stack ending at PR #12572; ARM64 Release build targeting Android API 24.
Description
After removing the CoreCLR host's libc++ dependency, investigate reducing the remaining libnet-android.release.so/libmonodroid.so footprint. A local-only proof of concept reduced the ARM64 host from 215,064 bytes to 58,408 bytes (72.8%), while still cold-starting a CoreCLR application on an ARM64 Android emulator.
The experiments fall into three groups: mechanical linker/compiler improvements, optional feature removal, and aggressive diagnostic removal. They should be evaluated independently rather than landed as one change.
Baseline
| Artifact | Bytes |
|---|---|
| Normal linked ARM64 Release DSO | 215,064 |
llvm-strip --strip-unneeded |
168,392 |
llvm-strip --strip-all |
167,928 |
Stripping preserved the JNI entry points in .dynsym. Internal P/Invoke implementations do not rely on .symtab: CoreCLR calls the live P/Invoke override callback, which returns function pointers. A stripped host successfully reached managed startup.
Measured progression
The values are cumulative and some optimizations interact, especially LTO and ICF.
| Configuration | Strip mode | Bytes |
|---|---|---|
| Baseline | --strip-unneeded |
168,392 |
Per-function/data sections + --gc-sections |
--strip-unneeded |
145,744 |
Experimental --icf=all before LTO |
--strip-unneeded |
139,856 |
--as-needed + --no-export-dynamic |
--strip-unneeded |
139,840 |
| Android packed relocations | --strip-unneeded |
130,656 |
Non-throwing string_view construction |
--strip-unneeded |
130,624 |
| Full LTO across host and linked archives | --strip-unneeded |
126,048 |
| Disable fast timing | --strip-unneeded |
101,120 |
| Disable decompressed-assembly disk cache | --strip-unneeded |
94,944 |
| Compile out Debug/Info logging | --strip-unneeded |
87,328 |
| Inline ARM64 atomics | --strip-unneeded |
85,168 |
| Disable configurable logging | --strip-all |
76,128 |
| Remove abort locations, simplify validation diagnostics, and use timing stubs | --strip-all |
58,408 |
Mechanical changes worth investigating
- Compile both the shared and static CoreCLR host targets with
-ffunction-sections -fdata-sections, then link with--gc-sections. The application-time unified native linker already enables GC, but the archive inputs need function granularity for it to be effective. - Add
--pack-dyn-relocs=android. Android packed relocations are supported by the API 24 minimum and saved about 9 KB. - Enable full LTO for the host and all static archives consumed by it. This saved about 4.6 KB, at the cost of native link time/memory and changed inlining.
- Add
--as-neededand remove the redundant--export-dynamic; this removed the unusedlibm.sodependency but saved only 16 bytes. - Consider
-mno-outline-atomicson ARM64. It removed the compiler-rt CPU-feature dispatcher and saved 2,160 bytes, but may make contended atomics slower on LSE-capable CPUs. - Replace provably in-range
string_view::substr()calls with direct{data, length}views. This avoids libc++ out-of-range abort helpers under size-oriented optimization. - Strip release runtime DSOs during pack production while retaining unstripped symbol artifacts for offline crash symbolication.
- Test
--icf=safe. It initially found no folds; after full LTO it matched the tested--icf=allresult in the minimized profile.--icf=allshould not be used without proving that function-address identity is irrelevant.
Optional feature reductions
Fast timing: approximately 25 KB
The PoC made FastTiming::enabled() a compile-time false, made initialization and managed timing P/Invokes no-ops, and removed Java_mono_android_Runtime_dumpTimingData from the export map. This removes startup timing collection, timing files/logcat output, and debug.mono.timing. A production implementation should probably retain dumpTimingData as a small no-op export for ABI compatibility.
Decompressed-assembly disk cache: approximately 6.2 KB
The PoC made cache initialization/writes no-ops and cache lookup return nullptr; LTO then removed the background writer, queue, mmap validation, hashing, and filesystem code. Normal in-memory decompression still worked. This may improve first launch slightly but makes every subsequent process launch decompress assemblies again, increasing warm-start CPU/battery use.
Aggressive diagnostic reductions
Compile out Debug/Info logging: approximately 7.6 KB
log_debugf() and log_infof() became compile-time no-ops. Warning, error, fatal logging, Android abort messages, and tombstones remained. Call arguments are no longer evaluated, so all call sites would need a side-effect audit.
Disable configurable logging: approximately 8.8 KB
The logging-category parser and reference-log initialization became no-ops. LTO removed assembly-loader diagnostics, GC spew, gref/lref file/logcat tracing, and timing-category configuration. Reference counters and GC behavior remained functional. This is likely suitable only for a separate minimal runtime flavor.
Remove abort source locations and simplify validation messages: approximately 17 KB
The PoC retained the primary fatal message, android_set_abort_message(), tombstones, and abort(), but removed file:line:column, pretty C++ function signatures, and the runtime function-name parser. This greatly reduces duplicated source paths/signatures but significantly harms field diagnostics unless unstripped symbols and stack addresses are available.
Rejected experiments
-Os/-Ozmade the stripped host larger and caused libc++ out-of-range abort helpers to survive where-O2optimized them away.--pack-dyn-relocs=android+relrsaved another 872 bytes, but RELR requires newer Android loaders and is unsuitable for the API 24 minimum.llvm-strip --strip-sectionssaved about 2 KB, but Android rejected the DSO withunsupported e_shentsize: 0x0 (expected 0x40).- Unrestricted
--icf=allsaved 5,888 bytes before LTO but can collapse distinct function addresses and is too risky as a default.
The final 58,408-byte ELF retained these dynamic JNI exports:
JNI_OnLoadJava_mono_android_Runtime_initInternalJava_mono_android_Runtime_registerJava_mono_android_Runtime_propagateUncaughtException
Its largest remaining areas were core runtime behavior: startup, GC bridge processing, P/Invoke dispatch, DSO loading, typemaps, and assembly probing/decompression.
Steps to Reproduce
- Prepare a Release
dotnet/androidnative build and build the ARM64 CoreCLRnet-android.releasetarget. - Record the linked and stripped baseline sizes.
- Apply each compiler/linker option independently and cleanly relink the ARM64 host.
- For feature experiments, compile out timing, the decompressed-assembly cache, and logging independently rather than combining them initially.
- Run
llvm-strip --strip-unneededor--strip-all, verifying the required JNI exports remain in.dynsym. - Replace
lib/arm64-v8a/libmonodroid.soin an API-24 CoreCLR sample APK, zipalign and sign it. - Cold-start it on an ARM64 emulator/device and verify managed UI startup, assembly loading/decompression, typemap setup, GC bridge initialization, and internal P/Invoke resolution.
- Benchmark cold/warm startup, memory, CPU, battery, native link time, and crash diagnosability for each candidate change across all supported ABIs.
Did you find any workaround?
A local uncommitted PoC demonstrates the possible size floor and isolates the candidate changes. The recommended first investigation is the behavior-neutral set: stripping with separate symbols, section GC, Android packed relocations, full LTO, --as-needed, and safe ICF. Timing, cache, and diagnostic removal should be separate opt-in decisions or a distinct minimal-runtime profile.
Relevant log output
# Baseline
linked-size=215064
strip-unneeded=168392
# Final aggressive PoC
strip-all=58408
pid=8696
errors=0
# Managed UI hierarchy
text="Hello, NativeAOT on Android!"
text="HelloNativeAOT"
# Invalid sectionless ELF experiment
E/linker: libmonodroid.so has unsupported e_shentsize: 0x0 (expected 0x40)
java.lang.UnsatisfiedLinkError: dlopen failed: unsupported e_shentsize
- Dominant language
- C#
- Stars
- 2.1k
- Forks
- 581
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 212
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dotnet/android
-
Area: App+Library Build
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Area: Debugger enhancement needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Area: Mono.Android
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
dotnet/android#9192 · 4 comments · 1 reaction ·
Maintainers usually reply within 1 day
-
needs-triage
Difficulty 5/5 Over a week Newbie friendliness 25/100
dotnet/android#12981 · 1 comment ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
521xueweihan/HelloGitHub#3845 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
lay295/TwitchDownloader#1675 ·
-
copilot documentation
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
space-wizards/RobustToolbox#7119 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
dotnet/Scaffolding#3881 ·
Maintainers usually reply within 2 days