[tomp]

> What people complain about with garbage collection are: (1) a fixed constant overhead they think is too high and will probably always think to high, (2) long pauses that are manageable in practice unless you are timing events with millisecond precision with a microcontroller.

I keep hearing this about "modern" GC and it keeps being very much not true in practice. I'm running IntelliJ IDEA (Java) on a laptop with 8GB of RAM, and it keeps freezing every so often. I'm suspecting GC causing paging. This is something that is obviously avoided with reference counting or manual memory management.

[jhgb]

> This is something that is obviously avoided with reference counting

You'd prefer your data being larger in memory due to refcount fields and slower to access due to atomic operations on those fields?

[tomp]

It's not like tracing GC is without memory overhead...

Slower is a question of priorities. I'd definitely trade off slower overall performance (I don't really need my IDE to be that performant... it's not like it's using 100% CPU, or even 10%!) but a huge improvement in latency (i.e. no catastrophic slowdowns / freezes).

[jhgb]

There are very few ways of having zero memory overhead, though.

Also, most of the flaws of Java's memory management seem to be concentrated in the part of the language that says that almost everything has to be an object with a header and on the heap. Remove that and your graph of objects to trace shrinks very substantially.

[withinboredom]

Interestingly, I was running out of memory, so I gave it more RAM (like 20GB) and it got even worse. Apparently it takes a long time to GC that much memory. I’d also rather amortize that pause. The loss of productivity due to a sudden pause is real.