RFR (S): 8067341: Modify PLAB sizing algorithm to waste less

[Eric Caspole]

Hi Thomas,
I like the new simpler math but I found the comment kind of confusing -

   61     // E.g. assume that if we recently used 100 words and a 
TargetPLABWastePct of 10.
   62     // If we had one thread, we could waste up to 10 words to meet 
that percentage.
   63     // Given that we also assume that that buffer is typically 
half-full, the new
   64     // desired PLAB size is 20 words.


So you mean this GC cycle used 100 words of 1 thread's PLAB when we are 
doing this calculation? Does the previous PLAB size matter or only the 
amount actually used?

   66     // We account region end waste fully to PLAB allocation (in 
the calculation of
   67     // what we consider as "used" below). This is not completely 
fair, but is a
   68     // conservative assumption because PLABs may be sized flexibly 
while we cannot
   69     // adjust inline allocations.


I know this comment was there before but how do the direct allocations 
affect the PLAB size? Because an object that does not fit immediately 
causes the the current PLAB to be discarded? So that increases the waste 
but it shows up in used()?

Thanks,
Eric



On 08/25/2015 12:06 PM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for the following change that modifies the PLAB
> sizing algorithm of G1 (only) to be much more stable and robust to
> varying sizes of memory allocation?
>
> The old (current for CMS) algorithm tends to create very large sized
> PLABs that mean a lot of waste at the end of PLABs and particularly at
> the end of regions. The other reason is that we can't figure out how the
> current algorithm actually is supposed to work. :)
>
> The end result is that PLAB sizes bounce a lot between some very low
> value and maximum value (which is or has been particularly bad for g1
> because of region boundaries), causing lots of wasted space. We have
> seen that particularly mixed gcs waste up to 50% of memory which caused
> useless GCs and degrading throughput significantly.
>
> This changeset replaces the current algorithm with something more robust
> (and rather conservative), which decreases the waste in most cases
> significantly. Still it typically sizes PLABs larger than default ones
> you would get with -XX:-ResizePLAB, improving performance.
>
> The change is commented in the changeset.
>
> In general, with fixed heap size, the change generally gives the same
> overall throughput on our throughput benchmarks. Total pause times
> decrease quite a bit, but since typically pause time is not an issue
> there is no end-to-end difference.
>
> The change has much more impact on applications that have a large
> variety of object sizes.
>
> This (and all other previous changes) affect automatic heap sizing
> though, so it may result in some at first glance unexpected results
> (like decreased heap usage). There may be some re-tuning of defaults in
> the future.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8067341
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8067341/webrev/
> Testing:
> jprt, perf benchmarks, tested internally in many applications for more
> than a year
>
> Thanks,
>    Thomas
>