-
Notifications
You must be signed in to change notification settings - Fork 826
Type subsumption cache, fix keys to reduce memory use #18875
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
/// Usage: | ||
/// let getValueFor = WeakMap.getOrCreate (fun key -> expensiveInit key) | ||
/// let v = getValueFor someKey | ||
let getOrCreate valueFactory = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it called getOrCreate
? Doesn't it always create a new table?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hope not. It calls ConditionalWeakTable.GetValue factory overload, so it should get the existing attached property or create a new one.
Just to have this data somewhere: as of current commit hit ratio measured over ComponentTests net10 is 75.8%, no eviction fails. |
The type subsumption cache was causing problems with the legacy 32 bit test projects.
This was swept under a rug for a few months, using a cache capacity override in tests.
In the course of #18872 I had to revisit this because it showed up again.
I captured a memory snapshot during tests to see what's going on.
Turns out the
TType
objects used as cache keys were the problem.They can reference a lot of additional lazy initialized data, including ginormous circular references. Now when we put them as cache keys, that can extend their life well beyond their natural lifespan. This was not a big problem memory wise in normal use, but somehow 32 bit tests couldn't handle it and had hard time GCing this.
For example If I weakly attached the cache to
TcGlobals
. This was correctly GC'd in other test projects but never collected in VS tests.Anyway, the fix is to use a synthetic key, created as a slim structural representation of
TType
in such a way as to guarantee equality soundness.I checked (by capturing telemetry from the test run) that the cache still works, hit ratio is still good and evictions happen ok.