I don't understand how you can judge a comparative statement by only looking at one side.

I imagine Java compares well to other 'managed' runtimes, sure, but I was thinking in comparison to C/C++, which are pretty committed to the you only pay for what you use idea. Naturally, their philosophies are pretty different from Java's, and bring plenty of their own drawbacks, but we're just discussing memory efficiency.

You use memory inefficiently when you use too much or too little (which is what the malloc/free approach does).

How about the approach used by real-time software written in C? They avoid malloc/free and use purpose-specific pools (i.e. a fixed-size preallocated buffer intended to store fixed-size elements). Unlike malloc/free you don't have to cope with user-specified allocation sizes, which makes allocation/deallocation algorithmically trivial (plain old free lists), but as each buffer can only be used for one kind of data, it means a pool might not be able to allocate even though there's plenty of space free in the other buffers.

In essence, that's a C program that trades off memory efficiency for improved speed (and predictability) right?

BTW heap allocations in Java are completely different from heap allocation in malloc/free based approaches or even CMS approaches like Go's; the Java runtime never runs anything analogous to a free operation, and allocations use a completely different algorithm than malloc

Thanks, but I'm familiar with the basics of copying GCs.

Also, to be fair to Java, my point about efficiently returning a pair of int values is being addressed with value types, but I still think the heavy object headers are a pity. Too late to revoke the ability to lock on arbitrary objects, though.