Re: memory allocation
Mark Space wrote:
But when things got really stressed out I remember the GC would run
twice (JPDA allows you to see when the GC runs, what kind of pass it's
doing, and memory allocation before and after). The first pass was a
"quick get rid of objects in the first generation" and the second pass
was "that didn't work, try to pack everything into an older generation
storage".
That is how generational collection works. There are young-generation
collections and tenured-generation collections. Objects that survive a few
young-gen collections eventually get tenured. The tenured collections take a
little longer, maybe more than a little, but they run less frequently. They
run when the tenured generation fills, not particularly when overall heap gets
full. The geezer heap is usually much larger than the young generation space.
<http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf>
But that's what I'm going by, not a spec or anything, but a remembered
account of watching a live system deal with a memory leak. I can't
guarantee that there aren't some situations where your technique would
be needed. I'll read the article you posted a link to now. It would be
interesting if there were some way to test this.
There are actually several different heap and GC strategies available, as the
referenced article mentions. Also, this is an area of active research. The
article dates back to Java 5; things may have changed a tad in version 6.
<http://java.sun.com/performance/reference/whitepapers/6_performance.html#2.3>
Other JVM brands have other GC ideas.
--
Lew