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

[Jon Masamitsu]

http://cr.openjdk.java.net/~tschatzl/8067341/webrev/src/share/vm/gc/g1/g1_globals.hpp.frames.html

   85   experimental(size_t, G1ExpectedAveragePLABOccupancyPercent, 50,           \
   86                "Expected average occupancy of PLABs after GC in percent.")  \
   87                range(0, 100)                                                \

Range should be (1, 100) since you divide by 
G1ExpectedAveragePLABOccupancyPercent
in the calculations?

http://cr.openjdk.java.net/~tschatzl/8067341/webrev/src/share/vm/gc/g1/g1EvacStats.cpp.frames.html

77     size_t const waste_used_for_calculation = used() > _region_end_waste ? used() - _region_end_waste : 0;

"waste_used_for_calculation" is a measure of "used" during the GC
so maybe a better name would be "used_for_waste_calculation" or
"used_for_PLAB_calculation"?

When _region_end_waste is high, waste_used_for_calculation under 
estimates the
amount used so under estimates the amount of waste (since the waste
is a percentage of waste_used_for_calculation ) and so lowers the size
of the next PLAB.  I can see that it scales reasonably.

Why G1ExpectedAveragePLABOccupancyPercent that can be different than 50?

If it is so that the user can scale the PLAB's up or down, what about 
scale factor
called G1PLABPercent?

   80     size_t const total_waste_allowed = waste_used_for_calculation * (TargetPLABWastePct / 100);
   81     size_t const cur_plab_sz = total_waste_allowed * (G1PLABPercent / 100)


G1PLABPercent would be easier to explain.  It's effect would be linear 
with its
value (as opposed to inversely proportional) and is a shorter name :-).

Jon


On 08/25/2015 09:06 AM, 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
>