On Dec 17, 2007 1:42 PM, Levi Pearson <levi at cold.org> wrote:
> In the literature regarding the performance of garbage collecting
> runtimes vs. explicit memory management, it has been shown that GC
> systems require roughly twice the heap space to be available as would
> be needed in an explicitly-managed heap in order to maintain optimal
> performance. Starving the GC heap leads to extreme performance
> degradation, so it's understandable that the jvm is configured with a
> fairly generous heap by default. Unfortunately, that means you get to
> hear both 'Java is slow!' when it isn't anymore, and 'Java is a
> resource hog!' which might be considered true, but keeps the former
> from being true in many cases.
No doubt that these situations exist. That of a person not allowing
the GC to allocate enough memory to be efficient. However, needing
double the heap size sounds like severely outdated information to me.
This article is pretty old, but even it disagrees with the literature
you mention.
http://www.ibm.com/developerworks/library/j-jtp01274.html
<from article>
Of course, allocation is only half the story -- most objects that are
allocated are eventually garbage collected, which also has costs. But
there's good news there, too. The vast majority of objects in most
Java applications become garbage before the next collection. The cost
of a minor garbage collection is proportional to the number of live
objects in the young generation, not the number of objects allocated
since the last collection. Because so few young generation objects
survive to the next collection, the amortized cost of collection per
allocation is fairly small (and can be made even smaller by simply
increasing the heap size, subject to the availability of enough
memory).
</from article>
So memory availability for the GC is important. No question there.
Nor am I questioning that you need more heap space than you would need
with manual heap management. However, the actual available size
required is only that of the young generation being copied to the next
generation. This is typically very small. So basically, your Java
heap needs to be about the size of your C heap plus some flux space
for generational copies of young objects turning mature, and young
objects jumping on and off the heap similar to a stack.
-Bryan