RFR (XS): JDK-8047976: Ergonomics for GC thread counts should update the flags

Thomas Schatzl thomas.schatzl at oracle.com
Thu Sep 25 09:01:09 UTC 2014


Hi,

On Thu, 2014-09-25 at 09:32 +0200, Thomas Schatzl wrote:
> Hi,
> 
> On Wed, 2014-09-24 at 08:51 -0700, Sangheon Kim wrote:
> > Hi all,
> > 
> > can I have reviews for the following small change to update 
> > G1ConcRefinementThreads variable?
> > And also I need a sponsor for this.
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8047976
> > 
> > Webrev:
> > http://cr.openjdk.java.net/~brutisso/8047976/webrev.00/ 
> > <http://cr.openjdk.java.net/%7Ebrutisso/8047976/webrev.00/>
> 
> Please update the flag during argument processing, not every time the
> method is called.
> 
> Somewhere in Arguments::set_g1_gc_flags() would be appropriate I think.
> 

Please also add a jtreg test case. At least one test case that verifies
that with G1 the G1ConcRefinementThreads is not zero if nothing or zero
is passed, and another one that checks that the value passed is taken
over.

The test could parse the output of -XX:+PrintFlagsFinal. The test
gc/arguments/TestObjectTenuringFlags.java shows how this is done.

There is also some behavior that seems to be wrong: if you manually set
the number of G1ConcRefinementThreads to zero (which means
"automatically select"), -XX:+PrintFlagsFinal still prints
"G1ConcRefinementThreads := 0". Imo even in this case the output should
contain the actual number of threads used.

At least if you set ConcGCThreads manually to 0, the flag is set to the
actual value after argument processing.

ParallelGCThreads also shows 0 here, but I think this part of bug
JDK-6979279 and should be fixed there.

Thanks,
  Thomas





More information about the hotspot-gc-dev mailing list