RFR (S): 8073204: Determining the desired PLAB size adjusts to the the number of threads at the wrong place

[Srinivas Ramakrishna]

Hi Sangheon --

Does the number of GC workers ever change dynamically within a stop-world
GC phase?
If not, you might save a little work by just doing the division once when
you decide the number of
workers at the start of the copying phase, and then use that value for the
remainder of the copying
phase of the collection when you know the number of workers won't change.
However, that is just a
nit, I am sure the work involved in calculating the value at each PLAB
refill shouldn't typically be a
big deal either way.

I might rename the _desired_plab_sz field to clarify that it's the net
value, say by calling it
_desired_net_plab_sz. (Alternatively, you could change the name of the
method
desired_plab_sz(int) to desired_plab_size_for_n_workers(int), but the
former seems better,
since the parameter already signals the intention for the latter.)

looks good to me otherwise.
-- ramki (openjdk: ysr)


On Mon, Apr 6, 2015 at 2:40 PM, Sangheon Kim <sangheon.kim at oracle.com>
wrote:

> Hi all,
>
> Please review this change to determine the desired PLAB size for current
> gc worker threads.
>
> Currently we calculate an optimal PLAB size with current number of gc
> workers.
> When the number of workers changes dynamically (-XX:+UseDynamicNumberOfGCThreads),
> the desired PLAB size returned(by desired_plab_sz()) is still tuned to the
> number of gc workers that has been used previously.
>
> This change is first calculate the desired PLAB value for a single gc
> worker and then return desired PLAB size according to the current number of
> threads.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8073204
>
> Webrev:
> http://cr.openjdk.java.net/~sangheki/8073204/webrev.01
>
> Test:
> JPRT
>
> Thanks,
> Sangheon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150406/ebbb1e3d/attachment.htm>