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