Skip to content

[TrimmableTypeMap] Parallelize assembly index construction during Java peer scanning #11491

Description

@simonrozsival

Part of #10958.

Assembly scanning is still eager and sequential. JavaPeerScanner.Scan(...) first calls AssemblyIndex.Create(...) for every assembly, then scans every populated index. This issue tracks a safe first step: parallelizing the independent index-building portion and documenting/refactoring any shared-state blockers for later scan parallelism.

Current locations

  • src/Microsoft.Android.Sdk.TrimmableTypeMap/Scanner/JavaPeerScanner.cs
    • Scan(...) builds all AssemblyIndex instances serially, stores them in assemblyCache, then scans each index.
  • src/Microsoft.Android.Sdk.TrimmableTypeMap/Scanner/AssemblyIndex.cs
    • AssemblyIndex.Create(...) builds one assembly index from a PEReader and assembly name.

Suggested implementation

  • Start with parallelizing AssemblyIndex.Create(...), since each assembly index is independent.
  • Merge results back into assemblyCache deterministically after parallel work completes.
  • Preserve scan/result ordering where it affects generated output.
  • Do not parallelize later phases that mutate shared dictionaries/caches until they are made thread-safe or refactored.

Acceptance criteria

  • Assembly index construction can run in parallel without changing generated typemap/manifest/JCW output.
  • Output remains deterministic.
  • Add or update tests as needed to cover stable output with multiple input assemblies.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    copilot`copilot-cli` or other AIs were used to author thistrimmable-type-map

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions