If I have to choose between years of experience plus a detailed understanding of the issues vs. a biased article doing obviously distorted comparisons, I won't have to think very long either.

Reread the article and give a little thought to the significance of the comparisons they do.

Ok, but is that because JVM allocates a generous amount of memory to itself, allowing it to allocate less space-efficiently, then spends its GC time piecing it back together? I'm sure malloc would work just as quickly if it was designed with the idea that it has as much as it wants to work with. And if JVM runs a more efficient algorithm, wouldn't that be +1 for the language JVM is written in? It isn't like "Java" makes the allocation; whatever logic it uses must inherently be written in a compiled language.
ta0kira

You know there exists:
http://linux.maruhn.com/sec/libgc.html

Yes, but the keyword here is if. And if the JVM had been implemented in hardware, we would be back to square one (there actuallly were experiments in this area in the mid-nineties, only the market was far too small back then too make it even remotely feasible).
The whole point is that many, many millions of research have gone into developing the best performing JVM; to do the same for a series of C/C++ projects would - in many cases and especially in larger projects - be absurdly expensive.

Sure - and how much of a difference would that leave between C++ and java?

You're too quick to accept the idea that malloc isn't already faster.

That article and the references it links to are heavily biased, primarily by selecting examples based on how badly they perform with malloc (but doing biased comparisons in a number of other ways as well).

A reasonable comparison must take into account the entire cost of the allocation / deallocation, which several of those comparisons don't and it should compare typical programs to similar programs, which none of those comparisons do.

There are some programs in which some versions of malloc do very badly. In my own experience, I've never worked on such a program for which simply switching to ptmalloc3 didn't fix the problem.
One of those references compared a C++ garbage collector that has many reasons (but no direct comparison) to be significantly slower than Java garbage collection vs. a few versions of malloc with a few programs selected for performing badly with those versions of malloc. The garbage collector did generally better than malloc, so you could expect a Java garbage collector to do even better. None of those versions of malloc were ptmalloc3.

I don't really understand the choice that was made to not make ptmalloc3 the default GNU malloc. I semi understand that in multi threaded applications doing malloc's from contending threads it will average slightly worse performance than the chosen default. But in non contending allocations (which are common even in a lot of multi threaded applications) it is slightly faster and it seems to be completely free of pathological cases (allocate/deallocate patterns that cause a major performance loss) while the default version has pathological cases.

In C++ on Linux (and somewhat on other platforms) you have the choice to substitute a different malloc or even something entirely different from malloc if you think your problem requires it.

But in typical application (not the ones chosen by those biased comparisons) any common version of malloc will perform better than any garbage collector.

You are correct that most memory allocation systems could benefit further from being more wasteful of virtual memory, assuming the waste of virtual memory itself has no cost. A garbage collector benefits more from that than a malloc or similar system. Malloc or similar systems typically don't waste a lot of virtual memory, so it is hard to say what makes a fair comparison if you assume wasting virtual memory is free then compare a GC version that does to a malloc version that doesn't. The more serious flaw is the whole assumption that wasting virtual memory is free.

Yes, much in the same way that "we'll just throw more hardware at it" is used as a serious solution to algorithm inefficiency.
ta0kira

I know that memory allocation can quickly become bottleneck if abused (experienced it). It isn't very fast for large blocks and certainly isn't instant. For example, in situation where you need to frequently allocate and then destroy blocks of data of larger but variable size, the best bet will be to allocate one block, reuse it and increase its' size when necessary. I also think that I saw recommendation to avoid allocating memory too often in game development. Also, AFAIK alloca is faster than malloc.

Garbage collector doesn't do the same thing as malloc. It frees memory, not allocates it.

By "perform better" I meant overall. All the costs associated with allocating and freeing memory compared between the two very different approaches to the issue.

In such a discussion, "malloc" or "garbage collector" don't refer to those parts of allocating or freeing memory but to the whole system of allocating and freeing memory in a system based on those parts.

That's because it only involves decrementing the stack pointer, but if used with C++ (i.e. in-place new) you have to manually call the destructor before it goes out of scope.
ta0kira