Programmers agonize over whether to allocate on the stack or on the heap.
Some people think garbage collection will never be as efficient as direct memory management, and others feel it is easier to clean up a mess in one big batch than to pick up individual pieces of dust throughout the day. This article pokes some holes in the oft-repeated performance myth of slow allocation in JVMs.

By the way, here are some tests I ran myself. I did not write the code, but I compiled it myself on my system. Tell me again that the benchmarks conclude Java is slow?

In the following tests, Java outperforms C on every test except for the "life" test. Tests were conducted with mingw gcc 3.4.2 on WinXP using -O2 optimization, and Java 1.5.0_04. Bigger numbers are better for all tests. Tests are averages throughout a range of sizes / numbers:

Fast Fourier Transform: C: 521.9 | Java: 528.4

Fibonacci: C: 249.6 | Java: 372.9

Life: C: 288.1 | Java: 150.8

Infilife: C: 359.1 | Java: 434.9

Again, in all tests with the exception of the Life test, Java performed better than C.