RFR: JDK-8077842 - Remove the level parameter passed around in GenCollectedHeap

[Mikael Gerdin]

Kim,

On 2015-06-03 02:06, Kim Barrett wrote:
> On Jun 2, 2015, at 1:56 PM, Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>
>> Hi Kim!
>>
>> I removed the unrelated formatting changes as suggested to minimize the conflicts with Bill's change. There will still be a conflict though since there were some actual changes as well.
>
> Right.  I’m just hoping to make that merge a little easier for whoever ends up needing to do it.
>
>> I also added the is_young_gen()/is_old_gen() in GenCollectedHeap as suggested. There is as you mentioned no way to determine which generation it is inside the generation. I haven't found any good way to implement that, and I'm also not sure I want to since I think that the generation shouldn't need to know this... I may be wrong though.
>
> That’s pretty much what I was thinking too.  Asking a generation for its Generation::Type smells a lot like asking it for its level.

I don't think that asking a Generation for its type is necessarily bad.
 From my view, level is a bad concept because it suggests that 
Generations can be freely reordered in the hierarchy when in fact they 
cannot. DefNew (and its sublcasses) must always be young and 
CardGeneration (and its sublcasses) must always be old.

My thought was that the constructors of those classes would pass a 
Generation::Type to the Generation constructor and set their type 
through that.

By doing the generation hierarchy cleanup we are moving towards a world 
where we most of the time know if we are dealing with an old or a young 
Generation object, but at some places we still need to figure out that 
and asking the heap for that is slightly strange to me.

/Mikael

>
>> New version:
>> http://cr.openjdk.java.net/~jwilhelm/8077842/webrev.05/
>>
>> Increment:
>> http://cr.openjdk.java.net/~jwilhelm/8077842/webrev.05.incremental/
>
> Looks good.
>