branchrust_reboot/main/pool_leak_experimentscancel
10 Commits over 31 Days - 0.01cph!
Fix regression with usemutexpool 1 leaking memory
Clean: remove editor-only add/remove fail counters
- also cache cell buffer length - jit might already do it automatically, so might be moot
Tests: compiles
Merge: from lprq
Prepping LPRQ segment implementation to use instead of current FuzzyPool
Tests: ran unit tests
Optim: inline segment storage and strip all ConcurrentQueue logic
My previous estimate of 10% degradation was off - it actually was 6ms vs 3.5ms. With these changes I consistently get 4ms for AllocDeallocMTShortLived(32,False) perf test - 15% loss, still acceptable
Tests: unit tests + AllocDeallocMTShortLived(32,False) perf test
Update(tests): port unit test fix from child branch
Tests: ran PoolTests batch of unit tests
Merge: from main
Random Editor crash seems to be gone on latest
Optim: use an over capacity segment to avoid segment churn
This keeps GC activity at 0. Perf seems 10% worse than Fuzzy, but it's acceptable. Though there's a bug somewhere.
Tests: AllocDeallocMTShortLived(32,False) perf test
Update: reimpleemnt whole of CoreCLR's ConcurrentQueue (same as in shipped mscorlib)
- added extra telemetry to track segment alloc/retire, general tries, gc activity
This time didn't rip out the segment growing logic, and looks like if it safely fits in one segment, it can be consistently used. Going to confirm if extra large segment is enough, then it'll be a viable candidate
Tests: ran unit tests and AllocDeallocMTShortLived(32,False) perf test
Update: try using CoreCLR's ConcurrentQueueSegment as a Pool implementation
Leaks a bit in busy MT perf tests, but breaks down at 32 threads (can leak up to 50% of the buffer). Not good enough on it's own
Tests: ran perf and unit tests
