RFR (M): 8067336: Allow that PLAB allocations at the end of regions are flexible

Tom Benson tom.benson at oracle.com
Tue Aug 18 15:03:49 UTC 2015

Hi Thomas,
It looks like the actual plab allocation changes are missing from 
g1Allocator.cpp - only an include was added...   ?

Aside from that, just a couple of minor comments.  I think the comment 
at line 193-194 in g1AllocRegion.hpp should say "...maximum word size of 
the allocation in desired_word_size" rather than "... in word_size".

In g1AllocRegion.inline.hpp, attempt_allocation and 
attempt_allocation_locked both have an error path that includes:
trace("alloc failed", *actual_word_size);

In the old version, the value handed to trace was the requested size, so 
here it should probably be min_word_size, since *actual_word_size is 
likely to be uninitialized.


On 8/18/2015 7:18 AM, Thomas Schatzl wrote:
> Hi all,
>    can I have reviews for this change that greatly reduces the amount of
> PLAB waste caused by blocks of memory that cannot be used at the end of
> regions?
> The idea is simple: instead of allocating a PLAB that does not fit the
> current region in a new region, look if it is possible to reuse the
> remainder of the current region for the current PLAB.
> E.g. if the current allocation region during GC has 19k words left, but
> PLAB size is 20k, and the next allocation is just a few words, return a
> 19k PLAB to the caller instead of wasting the 19k.
> There were no performance issues noticed here, the number of GCs tends
> to decrease significantly though.
> The main implementation idea is that in many allocation calls the single
> "word_size" parameter is replaced by minimum, desired and actual word
> size parameters which represent the minimum and desired (input)
> allocation sizes, and the actual word size an output parameter that
> indicates the actual number of words allocated.
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8067336
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8067336/webrev/
> Testing:
> jprt, vm.gc test list
> Thanks,
>    Thomas

More information about the hotspot-gc-dev mailing list