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.
Tom
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