Cast not your Perl before swine?

Levi Pearson levi at
Tue Dec 18 09:30:54 MST 2007

"Bryan Sant" <bryan.sant at> writes:
> I do understand that these researchers are supporters of GC, but their
> conclusion is that GC requires at least 2x the amount of memory to be
> comparatively efficient.  There's no doubt that GC has costs.
> Reference counting and the other tracking goodies obviously isn't
> free.  However, there are a number of ways that these costs are paid
> for.  One that I've already mentioned is the cache friendliness.
> Another big one is that GC will dramatically reduce the times an
> application invokes malloc/free.  The fake application these guys
> mocked likewise reduced the times their explicitly managed app calls
> malloc/free to an unrealistic level.

Okay, I see where our problem is.  You believe the GC guys who say
their GC is more efficient in general than manual memory management.
If you actually do some research, you'll find that there's no
quantitative evidence (aside from some completely synthetic benchmarks
like the one you created) that shows real-world programs written with
a modern garbage collector are faster than manual memory management.
There's plenty of theory as to why it /could/ be faster, but it just
doesn't play out that way.  I wanted to believe, too, but I spent a
long time researching the literature and found no evidence that it's
actually true, and plenty of evidence that it's false.

Of course, as you showed with your little synthetic benchmark, the
allocator is way faster in a copying collector, since it doesn't have
to do anything but increase a pointer.  That's not something that
automatically translates into a real-world performance gain, though.
I pointed out why, and in your response you showed an apparent lack of
understanding about how a generational collector actually works.  This
is going to be long enough without going into the gritty details, so
you'll either have to take my word for it or do some research.

Another point: You keep saying that they used obsolete GC algorithms.
They actually tested several.  In JDK 1.2, Java switched from a
mark-sweep-compact collector to a generational collector, which is
what the current JVM uses as well (though they've made some
performance tweaks).  The primary results that I cited were the ones
that used the generational collector.  So, they perhaps don't have the
latest and greatest GC tweaks from the latest JVM, but they are at
least using the same general algorithm.

Finally, you don't seem to understand how they did the manual
management simulation.  What they did was to run the program normally,
with GC enabled.  They instrumented the JVM to keep track of when
objects became unreachable by scanning the heap.  Then, they used the
results of that run to feed an oracle for the static memory management
simulator, which would free objects just before they become
unreachable.  They cite some other studies that support this being a
fairly accurate simulation of how manual management works.

Anyway, my whole point was to point out why the default JVM heap is so
large.  I contend that it is that way on purpose, so that you won't
run into performance degradation due to heap exhaustion.  You seemed
to think that it was uneccesarily large; I think they knew what they
were doing when they set the default.  Do you still think you know


More information about the PLUG mailing list