GC progress from JDK 8 to JDK 17

Re:GC progress from JDK 8 to JDK 17 by pkolaczk on Wednesday November 24, 2021 @01:32PM (#29333410)

Wait, fragmentation is not included in that 6%. It is that a GC with no fragmentation will already suffer a 6% overhead. A region-based GC will suffer from additional temporary fragmentation on top of those 6% as well, because some segments can be filled only partially with live objects until they are compacted. That effect might be actually bigger because allocations are done only from contiguous space, and it can't just try to allocate from the "holes" until it compacts them. And you also need some additional room to do allocations from in order to avoid too frequent GCs. So I'm practice it is not 6% but sometimes 600%.

[ Parent | on HN ]

Re:GC progress from JDK 8 to JDK 17 by foldr on Wednesday November 24, 2021 @01:48PM (#29333613)

Yes, sure. But you do still need to compare the total overhead associated with manual memory management (which is not zero) to the total overhead associated with GC. It's an empirical question which is larger in any given case. And of course it depends on the implementation of malloc and the implementation of GC.

I'm not expressing a view as to whether the overheads of manual memory management are typically comparable or not. I really don't know.

[ Parent | on HN ]

Re:GC progress from JDK 8 to JDK 17 by pkolaczk on Wednesday November 24, 2021 @01:57PM (#29333703)

The total memory overhead of manual memory management can be virtually zero if you're careful enough to avoid fragmentation (and you can because it is manual, so you control a lot of details). There is for example no constant header for each allocated chunk. In Java you pay additional 16B for each allocated object and you can't get away from that overhead.

[ Parent | on HN ]

Re:GC progress from JDK 8 to JDK 17 by foldr on Wednesday November 24, 2021 @02:04PM (#29333780)

Yes, manual memory management can always be better with arbitrary amounts of tuning. However, I think the more interesting question is how the overheads compare in typical applications written in a reasonably straightforward and maintainable style. In practice, fragmentation can be a difficult problem to avoid when using manual memory management. For example, Firefox struggled with it for a long time.

[ Parent | on HN ]

Re:GC progress from JDK 8 to JDK 17 by pkolaczk on Wednesday November 24, 2021 @02:13PM (#29333909)

A web browser is a huge and complex app. The argument it struggled with memory issues is moot if you can't show a comparably featured app written in Java to compare memory use.

Anyways, I've got plenty of anecdotal evidence where Java apps take order of magnitude more memory than their close counterparts written in languages that use manual memory management. Not browsers, but things like benchmarking tools, webservers or even duplicate file finders (shameless plug: https://github.com/pkolaczk/fclones#benchmarks - there is one Java app there, see its memory use :D)

[ Parent | on HN ]

Re:GC progress from JDK 8 to JDK 17 by foldr on Wednesday November 24, 2021 @02:26PM (#29334057)

We’re talking at cross purposes here. I did say that I wasn’t expressing a view as to whether the overheads of manual memory management are typically larger than the overheads of GC. I don't know if they are or not.

The point I was making was just that you do need to compare empirically the typical overheads of each to make a meaningful comparison. The 6% figure in isolation doesn’t tell us very much.

As you point out, it is difficult to make these comparisons on the basis of anything other than anecdotal evidence, since it is rare for applications of significant size or complexity to be implemented in multiple languages.

[ Parent | on HN ]