News for hackers. Stuff that matters.
Re:Building a bare-metal bootable game for Raspberry Pi in C# by neonsunset on Monday December 11, 2023 @09:49AM (#38601105)
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...

Re:Building a bare-metal bootable game for Raspberry Pi in C# by bob1029 on Monday December 11, 2023 @02:09PM (#38604047)
> 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.

Re:Building a bare-metal bootable game for Raspberry Pi in C# by evntdrvn on Monday December 11, 2023 @04:11PM (#38605536)
If you raise issues on the asp.net repo and tag David Fowler, he's pretty passionate about removing allocations whereever possible :)