Hacker News new | ask | show | jobs
by jhgb 1869 days ago
> 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?

1 comments

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

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.