On Dec 17, 2007 1:42 PM, Levi Pearson <[EMAIL PROTECTED]> 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 /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
