RFR(XS): 8198510: Limit GC threads for small Java heap

[Doerr, Martin]

Hi Thomas,

thanks for discussing this topic with your colleagues.

I have a webrev which simply switches on UseDynamicNumberOfGCThreads by default:
http://cr.openjdk.java.net/~mdoerr/8198510_gc_threads/webrev.01/

I'll test it in our nightly tests. If I get approval from 2 reviewers and no objections, I'll push it to the submission forest and later to jdk/hs.

Best regards,
Martin


-----Original Message-----
From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] 
Sent: Mittwoch, 21. Februar 2018 16:38
To: Doerr, Martin <martin.doerr at sap.com>; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(XS): 8198510: Limit GC threads for small Java heap

Hi,

On Wed, 2018-02-21 at 14:12 +0000, Doerr, Martin wrote:
> Hi Thomas,
> 
> thanks for the quick response.
> 
> I think enabling -XX:+UseDynamicNumberOfGCThreads would be also fine
> if this is acceptable. I don't know why it's currently off by
> default.

We talked about this a bit internally, and nobody knows why (apart from
potential "it's a change in behavior" fears), but nobody objected. :)

> JDK-8172792 will only address G1, right?

Where it would require too much extra work, yes. G1 already has all the
infrastructure to track various metrics, and actually already tracks
many of the relevant ones found so far. It is "only" a matter of
determining the relevant metrics for the various GC phases in more
detail, wiring them to produce a number of threads, and of course
testing.

From what I can see from the CRs linked to JDK-8172792 (which is not a
complete list), the reference processing ones do not specifically
mention g1 only. :)

We will not remove the current thread sizing policy (limit threads by
max heap size, i.e. use 1 thread for every 64MB of max heap) enabled by
-XX:+UseDynamicNumberOfGCThreads in the other collectors.

So at worst by making UseDynamicNumberOfGCThreads default, the VM would
behave as with your suggested change.

Thanks,
  Thomas