Hacker News Reader

Comment by bob1029 | Hacker News Reader

All I want for Christmas this year is for Java Epsilon GC [0] to be made available in .NET.

Maybe I am missing something, but this doesn't seem like a very complicated ask. Granted, some developers would absolutely blow their feet off with this, but that's why you don't make it a default thing. Hide it behind a csproj flag and throw a runtime exception if the developer presses the GC.NapTime() red button without configuring the runtime appropriately.

There are a lot of use cases where you can strategically reorganize the problem and sidestep the need to meticulously clean your heaps. Running a supervisory process (which is allowed to GC itself) that periodically resets the principal ZGC process via business events or other heuristics is a pretty obvious path to me. Round-based multiplayer gaming seems well-aligned if you can keep allocations to a dull roar.

[0]: https://openjdk.org/jeps/318

View on HN

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.tryst...

> 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.

If you raise issues on the asp.net repo and tag David Fowler, he's pretty passionate about removing allocations whereever possible :)

Something like this: https://github.com/kkokosa/UpsilonGC ?

Huh. That’s interesting.

I can see something like this be useful in certain circumstances. But I would intuitively assume that gen0 collection is probably a better compromise.

Reply on news.ycombinator.com