You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The entire motivation for the trimmable type map is NativeAOT support, but there is no issue tracking end-to-end validation of building and running an app with NativeAOT + trimmable type map.
Why this matters
NativeAOT has unique concerns that differ from the CoreCLR + ILLink path:
No ILLink custom steps under NativeAOT — the trimmable path avoids custom trimmer steps, but we need to verify ILC's TypeMap intrinsic handles our attributes correctly (trim targets, aliases, associations).
MakeGenericType restrictions — NativeAOT restricts MakeGenericType to pre-compiled generic instantiations. While [TrimmableTypeMap] Handle generic invoker type resolution at runtime #11046 showed this is not a real concern for invoker types, we should validate there are no other paths that hit this.
crossgen2 is N/A — the perf optimization of pre-compiling the NativeHashtable via crossgen2 ([TrimmableTypeMap] Performance considerations #10795) only applies to CoreCLR. NativeAOT pre-compiles the lookup intrinsically, but we need to verify the startup perf is acceptable.
Acceptance criteria
A sample app (at minimum HelloWorld-level, ideally with AndroidX) builds successfully with PublishAot=true + _AndroidTypeMapImplementation=trimmable
The app launches and runs on a device/emulator
Type map lookups work: managed-to-Java and Java-to-managed
JCW registration via RegisterNatives works
ProGuard rules are generated correctly from ILC output
No MakeGenericType or reflection failures at runtime
Startup time is measured and compared to CoreCLR + trimmable baseline
This is a validation/integration issue, not a feature implementation issue. Most of the trimmable type map code is runtime-agnostic. The goal is to identify and fix any NativeAOT-specific gaps.
Part of #10788
Summary
The entire motivation for the trimmable type map is NativeAOT support, but there is no issue tracking end-to-end validation of building and running an app with NativeAOT + trimmable type map.
Why this matters
NativeAOT has unique concerns that differ from the CoreCLR + ILLink path:
$(IlcGenerateMetadataLog)/$(IlcGenerateDgmlFile), but these are large and slow to parse.TypeMapintrinsic handles our attributes correctly (trim targets, aliases, associations).MakeGenericTyperestrictions — NativeAOT restrictsMakeGenericTypeto pre-compiled generic instantiations. While [TrimmableTypeMap] Handle generic invoker type resolution at runtime #11046 showed this is not a real concern for invoker types, we should validate there are no other paths that hit this.NativeHashtablevia crossgen2 ([TrimmableTypeMap] Performance considerations #10795) only applies to CoreCLR. NativeAOT pre-compiles the lookup intrinsically, but we need to verify the startup perf is acceptable.Acceptance criteria
PublishAot=true+_AndroidTypeMapImplementation=trimmableRegisterNativesworksMakeGenericTypeor reflection failures at runtimeDependencies
Notes
This is a validation/integration issue, not a feature implementation issue. Most of the trimmable type map code is runtime-agnostic. The goal is to identify and fix any NativeAOT-specific gaps.