JDK-8073204 : Determining the desired PLAB size adjusts to the the number of threads at the wrong place
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-02-16
  • Updated: 2015-06-03
  • Resolved: 2015-04-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b66Fixed
Related Reports
Cloners :  
Relates :  
Description
When calculating the size of the next PLAB we pass along the current number of gc workers, calculating an "optimal" PLAB size for that number of gc workers, that is fed directly to the desired PLAB size predictor.

When the number of workers changes dynamically (with -XX:+UseDynamicNumberOfGCThreads), the desired PLAB size value returned is still tuned to the number of threads that has been used previously, losing performance.

A better solution would be to feed the PLAB size predictor the value for a single thread, and calculate the actual desired size according to the current number of threads instead.
Comments
Fix is to remove the no_of_gc_workers parameter for PLABStats::adjust_desired_plab_sz(), and add one for PLABStats::desired_plab_sz() (and rename the two methods to spell out "sz")
16-02-2015

ILW: I: medium -> directly affects the size of PLABs, i.e. copying performance. L: low -> the number of users of -XX:+UseDynamicNumberOfGCThreads is assumed to be very low W: medium -> disable -XX:+UseDynamicNumberOfGCThreads, use -XX:-ResizePLAB, or manually set PLAB size at the cost of performance MLM -> P4
16-02-2015