RFR: 8057632 - Remove auxiliary code used to handle the generations array

[Kim Barrett]

On Sep 4, 2014, at 7:54 PM, Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> 
> This is the next part of the generation array removal. I have split this change into several parts to ease the review. These webrevs build on top of each other.

Quoting from https://bugs.openjdk.java.net/browse/JDK-8055702

 Today GenCollectedHeap contains an array with room for ten
 generations, and there is plenty of code that is written in a very
 generic way to allow for this many generations. However, there is
 also plenty of code that assumes we only use two generations and any
 attempt to use more would fail with the current code. In practice we
 only use two generations and there are no reason to maintain the
 illusion that we could use more.

Has there been any discussion of whether removing support for many
generations is indeed desirable, vs fixing the places where that
possibility isn't properly supported?  It was a long time ago, and I
haven't even looked for references yet, but I vaguely recall seeing
measurements showing some applications could benefit significantly
from such.  I think it had to do with applications that undergo major
phase changes, where substantial data structures lasted for much of
the duration of a phase but then were dropped on those phase
transitions - moving such data to some intermediate generation that
was processed more often than "old" but less often than "young" was
thought to be beneficial.  [It's also entirely possible that I'm
completely misremembering, as this would have been from back in the
early 1990s.]

Maybe the answer to such an application now is G1?