Compute Java name hashes on demand instead of pre-computing both#11132
Merged
jonathanpeppers merged 1 commit intomainfrom Apr 17, 2026
Merged
Conversation
Replace JavaNameHash32/JavaNameHash64 with a single JavaNameHash field in both MonoVM and CoreCLR type mapping generators. Hashes are now computed on demand in GenerateAndSortJavaHashes() where the target is known, instead of pre-computing both 32-bit and 64-bit hashes during Construct(). Since each architecture gets its own generator instance, only one hash width is ever needed. This eliminates redundant computation and storage. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR reduces typemap generator overhead by computing Java type name hashes only for the target bitness being emitted (32-bit or 64-bit), instead of always computing both during construction. This affects both the MonoVM and CoreCLR typemap native assembly generators in Xamarin.Android.Build.Tasks.
Changes:
- Replace
JavaNameHash32/JavaNameHash64with a singleulong JavaNameHashin both generators. - Move hash computation and Java map sorting into
GenerateAndSortJavaHashes()wheretarget.Is64Bitis known, and collapse the two hash comparers into one. - Remove unused local
HashSet<uint>/HashSet<ulong>allocations in the CLR generator’s removed hashing path.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/Xamarin.Android.Build.Tasks/Utilities/TypeMappingReleaseNativeAssemblyGenerator.cs | Compute/sort Java name hashes per-target in GenerateAndSortJavaHashes(), use a single hash field and comparer, and remove eager dual-hash computation. |
| src/Xamarin.Android.Build.Tasks/Utilities/TypeMappingReleaseNativeAssemblyGeneratorCLR.cs | Same on-demand per-target hash computation/sort refactor for the CoreCLR generator; removes unused hash set locals from the deleted hashing method. |
simonrozsival
approved these changes
Apr 17, 2026
Member
simonrozsival
left a comment
simonrozsival
left a comment
There was a problem hiding this comment.
CI failures are unrelated.
jonathanpeppers
deleted the
jonathanpeppers/dev-peppers-hash-java-names-on-demand
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Both MonoVM and CoreCLR type mapping generators were pre-computing
32-bit and 64-bit Java name hashes during
Construct(), even thoughonly one width is ever used per architecture target. Since each ABI gets
its own generator instance (the data is not shared across
android-arm/android-arm64/android-x86/android-x64), the unused hash was
pure overhead.
This PR replaces
JavaNameHash32/JavaNameHash64with a singleulong JavaNameHashfield and moves the computation intoGenerateAndSortJavaHashes(), wheretarget.Is64Bitis already known.The two separate comparers (
JavaNameHash32Comparer/JavaNameHash64Comparer) are collapsed into oneJavaNameHashComparer.The CLR generator's
HashJavaNames()also builtHashSet<uint>andHashSet<ulong>locals that were never read -- those are removed aswell.