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.

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.

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)

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.