[Android] Investigate and reduce `coreclr_static.a` size

[kotlarmilos]

Description

The static library coreclr_static.a, which includes all runtime object files for Android, is currently 701,631,922 bytes (~700 MB). This does not affect static linking behavior but significantly impacts package size.

Source code: https://github.com/dotnet/runtime/blob/main/src/coreclr/dlls/mscoree/coreclr/CMakeLists.txt

Tasks

• Investigate contents of coreclr_static.a and identify large contributors
• Trim unused object files or symbols

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @hoyosjs
See info in area-owners.md if you want to be subscribed.

[filipnavara]

That sounds like it includes all the debug symbols. Do we have some comparison with MonoVM? Were the MonoVM static libraries stripped?

[kotlarmilos]

Here is a comparison in bytes with MonoVM from Microsoft.NETCore.App.Runtime[.Mono].android-arm64.10.0.0-preview.6.25316.109:

579840 runtimes/android-arm64/native/libSystem.Globalization.Native.a
34880 runtimes/android-arm64/native/libSystem.IO.Compression.Native.a
833190 runtimes/android-arm64/native/libSystem.Native.a
2061684 runtimes/android-arm64/native/libSystem.Security.Cryptography.Native.Android.a
172616 runtimes/android-arm64/native/libbrotlicommon.a
419584 runtimes/android-arm64/native/libbrotlidec.a
3960526 runtimes/android-arm64/native/libbrotlienc.a
701268296 runtimes/android-arm64/native/libcoreclr_static.a

566528 runtimes/android-arm64/native/libSystem.Globalization.Native.a
34616 runtimes/android-arm64/native/libSystem.IO.Compression.Native.a
825846 runtimes/android-arm64/native/libSystem.Native.a
2057724 runtimes/android-arm64/native/libSystem.Security.Cryptography.Native.Android.a
171832 runtimes/android-arm64/native/libbrotlicommon.a
418696 runtimes/android-arm64/native/libbrotlidec.a
3959934 runtimes/android-arm64/native/libbrotlienc.a
2142872 runtimes/android-arm64/native/libmono-component-debugger-static.a
109494 runtimes/android-arm64/native/libmono-component-debugger-stub-static.a
4221190 runtimes/android-arm64/native/libmono-component-diagnostics_tracing-static.a
47464 runtimes/android-arm64/native/libmono-component-diagnostics_tracing-stub-static.a
511248 runtimes/android-arm64/native/libmono-component-hot_reload-static.a
74826 runtimes/android-arm64/native/libmono-component-hot_reload-stub-static.a
317602 runtimes/android-arm64/native/libmono-component-marshal-ilgen-static.a
95534 runtimes/android-arm64/native/libmono-component-marshal-ilgen-stub-static.a
44559048 runtimes/android-arm64/native/libmonosgen-2.0.a

I tried stripping symbols using strip -S, but it didn't reduce the file size.

[kotlarmilos]

I was using the Apple toolchain, not the Android one. I produced a stripped static library

26723754 runtimes/android-arm64/native/libcoreclr_static_stripped.a

using the following commands:

toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-ar -x libcoreclr_static.a 

for f in *.o; do
    /toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-strip --strip-debug "$f"
done

toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-ar rcs libcoreclr_static_stripped.a *.o

[jkotas]

I would prioritize diagnosability over optimizing package size. If we strip symbols by default, what is the debugging the runtime code going to be like?

[kotlarmilos]

I am thinking to provide symbols as separate file. There are two nuget packages:

Microsoft.NETCore.App.Runtime.android-arm64.10.0.0-ci.nupkg
Microsoft.NETCore.App.Runtime.android-arm64.10.0.0-ci.symbols.nupkg

Currently, the .symbols.nupkg contains the same content as the base package + debug symbols. I suggest providing stripped library in the base package and the stripped library + symbols in symbols.nupkg.

[filipnavara]

I would prioritize diagnosability over optimizing package size. If we strip symbols by default, what is the debugging the runtime code going to be like?

I'm torn on this.

I'd prefer to match what we do for dynamic libraries where the symbols are distributed separately. Unfortunately that may not be a viable option for static libraries, depending on the tooling.

Failing that, I think the safe path is to do what we do for MonoVM, which presumably is doing some kind of stripping?