RFR: 8239825: G1: Simplify threshold test for mutator refinement
sangheon.kim at oracle.com
sangheon.kim at oracle.com
Tue Mar 10 21:17:56 UTC 2020
Hi Kim,
On 3/3/20 6:16 PM, Kim Barrett wrote:
> Please review this change to the handling of "padding" for the threshold
> used to decide whether a mutator thread should perform concurrent
> refinement. Rather than doing a slightly tricky (because of potential
> overflow) computation every time a mutator thread completes a buffer,
> instead perform that computation once and record the result for repeated
> use.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8239825
>
> Webrev:
> https://cr.openjdk.java.net/~kbarrett/8239825/open.00/
Looks good as is.
-------------------
src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp
326 // Artificially increase mutator refinement threshold.
327 void set_max_cards_padding(size_t padding);
- This method is not used even 8240133 and 8139652. I'm okay leaving as
is if you think it may be used in the future.
330 void discard_max_cards_padding();
- You changed the member name from '_max_cards_padding' to
'_padded_max_cards' but it is not reflected on the method name.
Is this intended? I don't need a new webrev for this change if you
would like to change it.
Thanks,
Sangheon
>
> Testing:
> mach5 tier1-5 along with changes for JDK-8240133 and JDK-8139652.
> Local (linux-x64) hotspot:tier1 with just this change.
>
More information about the hotspot-gc-dev
mailing list