[release/10.0] Fix hash collision in TypeMapLazyDictionary causing non-deterministic ArgumentException #123517
+4
−8
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.
Backport of #123502 to release/10.0
/cc @AaronRobinsonMSFT @copilot
Customer Impact
When large numbers of
TypeMapAssociationAttributeexist, it can occur that collisions of type names (strings) occur. The current approach ignored the possibility of collision and simply acquired the result ofGetHashCode()and inserted that as a key into aDictionary<,>. This meant there was no opportunity to handle the case when two non-equalstringinstances generate the same hash code. Using the hash code directly was done to avoid the non-trivial increase in memory usage imposed by using thestringinstances as the key.The solution is to use the
stringas the key instead.Regression
Testing
Verified using a CsWinRT repro case. Prior to this fix a collision would occur 1 / 100 times run. After this change the repro ran for more than 1000 iterations with no collisions.
Risk
Low. This new approach does increase the baseline amount of memory when the
TypeMapis used on coreclr. This was deemed acceptable since the coreclr isn't considered the P1 scenario forTypeMap. The native AOT, the P1 scenario forTypeMap, is not impacted by this change.