RFR (S): 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp

[Joseph Provino]

I assigned https://bugs.openjdk.java.net/browse/JDK-8074546
to myself yesterday and made the changes in my local repo.

If someone else is working on this, I'll reassign it to them.

BTW, should  parGCAllocBuffer.cpp, parGCAllocBuffer.hpp,, 
parGCAllocBuffer.inline.hpp
be renamed to plab.cpp, plab.hpp, plab.inline.hpp

Or should "plab" be capitalized differently?

joe


On 3/31/2015 6:28 AM, Thomas Schatzl wrote:
> Hi again,
>
> On Tue, 2015-03-31 at 09:32 +0200, Thomas Schatzl wrote:
>> Hi Jon,
>>
>> On Sun, 2015-03-29 at 12:35 -0700, Jon Masamitsu wrote:
>>> Thomas,
>>>
>>> It's not clear to me that the name change
>>> G1ParGCAllocBuffer to G1PLAB is a change for the better.
>>>   From the base class name  ParGCAllocBuffer, I could guess
>>> the G1 version is G1ParGCAllocBuffer but I would not guess
>>> G1PLAB.  Can you motivate that name (G1PLAB) for me?
>> "PLAB" is a commonly used and more concise abbreviation for this kind of
>> data structure. We ourselves use "Promotion Local Allocation
>> Buffer" (sometimes also "Parallel Local...") e.g. in the description of
>> the *PLAB* switches. Also in literature (see some GC papers) that name
>> is used for this kind of data structure (note that they apparently use
>> our naming).
>>
>> ParGCAllocBuffer misses the information about it being about
>> "promotion"/"parallel" and "local" too, and is longer to type.
>>
>> I think it is prudent to follow existing naming for stuff like that
>> instead of re-inventing it within the same code.
>    talked to StefanK a bit about this, and we think that it would be good
> to do this renaming in JDK-8074546 before this change goes in.
>
> This would avoid having the subclass renamed temporarily, but not the
> parent.
>
> I will provide a new webrev then.
>
> Thanks for looking at this.
>
> Thanks,
>    Thomas
>
>