Skip to content

[TrimmableTypeMap] NativeAOT end-to-end validation #11052

@simonrozsival

Description

@simonrozsival

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:

  1. ILC post-trim type list — ILC does not yet expose the list of types it kept in the type map (tracked in TypeMap API: For trimmed and nativeaot builds, provide a list of the types kept by the typemap runtime#120204). This is needed for post-trim ProGuard generation. The current workaround is $(IlcGenerateMetadataLog) / $(IlcGenerateDgmlFile), but these are large and slow to parse.
  2. 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).
  3. 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.
  4. ProGuard generation after ILC — the build pipeline needs different plumbing to generate ProGuard rules from ILC output vs ILLink output ([TrimmableTypeMap] Generate ProGuard for types in type map #10790).
  5. 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

Dependencies

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    copilot`copilot-cli` or other AIs were used to author thisneeds-triageIssues that need to be assigned.trimmable-type-map

    Type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions