3 ms·
Given that GC exists as a standalone .dll / .so when targeting JIT, you could theoretically replace it with your own implementation that only supports allocatio
by neonsunset 3y ago
Given that GC exists as a standalone .dll / .so when targeting JIT, you could theoretically replace it with your own implementation that only supports allocation. But realistically this may not be desirable since the allocation traffic in applications can be pretty high and require a lot of RAM to not quickly go OOM without reclaiming the memory.
There is also API to temporarily suppress GC: https://learn.microsoft.com/en-us/dotnet/api/system.gc.trystartnogcregion https://learn.microsoft.com/en-us/dotnet/api/system.gc.tryst...
- bob1029 3y ago> the allocation traffic in applications can be pretty high My use case is such that I have already done everything in my power to minimize allocations, but I have to use some parts of the framework which generate a small amount of ambient trash as a consequence of their operation. My desire to suppress GC is not so much about my own allocation story as it is keeping the gentle, gradual allocations from auxiliary framework items from triggering a nasty GC pause. My biggest pain point - every time an HttpContext is used there is some degree of trash that accumulates. I have zero control over this unless I want to write my own HTTP+web socket implementation from zero. The current solution for me is to GC as often as possible in workstation mode, but I would find a zero GC solution even better for this specific scenario. I suspect "rapid GC" is only sustainable while total working set remains small-ish. In the future, I may want to operate with working sets measured upwards of 10 gigabytes.
- evntdrvn 3y agoIf you raise issues on the asp.net repo and tag David Fowler, he's pretty passionate about removing allocations whereever possible :)