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
{{ message }}
Repository navigation
Bad hash code calculation in PSMethodInvocationConstraints results in explosion of static cache #24964
The hash code calculation in PSMethodInvocationConstraints only counts in the array members but not their elements, so the returned hash code would be different for two PSMethodInvocationConstraints instances that hold exactly the same elements in their array members.
The hash code of PSMethodInvocationConstraints is used by the static cache PSInvokeMemberBinder.s_binderCache because PSMethodInvocationConstraints is a member of the key for that cache, so you end up with every request being a cache miss in PSInvokeMemberBinder.s_binderCache.
changed the title [-]Bad hash code calculation in PSMethodInvocationConstraints results in explosion of static cache[/-][+]Bad hash code calculation in `PSMethodInvocationConstraints` results in explosion of static cache[/+]on Feb 12, 2025
In this case I was looking at a memory profile and deduced it through circumstantial evidence. Then used more runtime inspection to see that the hash codes were different for seemingly empty objects (of type PSMethodInvocationConstraints) where those PSMethodInvocationConstraints were used as a tuple elements which was a cache key.
There are certainly all kinds of ways to measure at runtime, for example by adding telemetry metrics. Microsoft seems to have at least 10 different ways they measure stuff like this :)
Activity
crazyjncsu commentedon Feb 6, 2025
crazyjncsu commentedon Feb 6, 2025
this cache is the blue ring over the top:
crazyjncsu commentedon Feb 6, 2025
mayfieldiv commentedon Feb 10, 2025
It looks like this bug was introduced in #12412, specifically https://github.com/PowerShell/PowerShell/pull/12412/files#diff-0ddb35aa9c54dfe72659129d2153e6d838772a153c9c12aced85a33e7d6d9b1bL1997-R2014
[-]Bad hash code calculation in PSMethodInvocationConstraints results in explosion of static cache[/-][+]Bad hash code calculation in `PSMethodInvocationConstraints` results in explosion of static cache[/+]iSazonov commentedon Feb 13, 2025
Jake Morgan (@crazyjncsu) Could you please share how you measure cache misses? Perhaps we could add a test to exclude regressions in future.
microsoft-github-policy-service commentedon Feb 13, 2025
📣 Hey Jake Morgan (@crazyjncsu), how did we do? We would love to hear your feedback with the link below! 🗣️
🔗 https://aka.ms/PSRepoFeedback
crazyjncsu commentedon Feb 13, 2025
Ilya (@iSazonov)
In this case I was looking at a memory profile and deduced it through circumstantial evidence. Then used more runtime inspection to see that the hash codes were different for seemingly empty objects (of type PSMethodInvocationConstraints) where those PSMethodInvocationConstraints were used as a tuple elements which was a cache key.
There are certainly all kinds of ways to measure at runtime, for example by adding telemetry metrics. Microsoft seems to have at least 10 different ways they measure stuff like this :)