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

[Bengt Rutisson]

Hi Kim,

On 9/18/14 8:56 PM, Kim Barrett wrote:
> 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?

Yes, we did discuss this and I think Jesper's work is the right thing to 
do (even though I haven't looked at his latest webrev).

Some background. The generations abstraction was introduced to support 
the train collector, where multiple generations was a central concept. 
When the train collector was removed the code was never cleaned up 
properly. Thus, I consider the work that  Jesper does now cleanups that 
reduce our technical debt.

When the train collector was removed we were left with only collectors 
that support two generations. Note that only two of our GC (CMS and 
SerialGC) actually use the generations abstraction. That means that the 
code is unnecessarily complex and as Jepser points out it has probably 
deteriorated in a way that it will not be easy to just add a generation.

Having said all that, I do agree that an intermediate generation may be 
useful in some cases. But I think if we would add that we would most 
likely add it to G1. In G1 it is actually fairly straight forward to do 
that, but it will not make use of the current generation abstraction. 
So, Jesper's change does not limit our future plans in any way for G1 
(or for ParallelGC for that matter).

Keeping the generations abstraction around would however limit our 
flexibility since it makes any changes to CMS and SerialGC more 
difficult and error prone than they have to be.

Thanks,
Bengt

>