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

Doerr, Martin martin.doerr at sap.com
Wed Feb 21 14:12:57 UTC 2018

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.

JDK-8172792 will only address G1, right?

Best regards,

-----Original Message-----
From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] 
Sent: Mittwoch, 21. Februar 2018 14:56
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


On Wed, 2018-02-21 at 13:48 +0000, Doerr, Martin wrote:
> Hi,
> the VM currently starts a large amount of GC threads on systems with
> many CPUs regardless of the Java heap size.
> This doesn't make sense for very small heap sizes.
> The number of ParallelGCThreads can be observed by e.g.:
> jdk/bin/java -Xmx128m -XX:+PrintFlagsFinal -version|grep GCThreads
> My proposal is to use up to 1 GC thread per 64 MB of heap:
> http://cr.openjdk.java.net/~mdoerr/8198510_gc_threads/webrev.00/
> Please review.

  did you try using -XX:+UseDynamicNumberOfGCThreads? It uses exactly
the same policy iirc.

I would rather discuss making -XX:+UseDynamicNumberOfGCThreads default
true instead of adding the same policy at a second place.

Also there is some work in that direction pending as part of JDK-
8172792 [1]. As I am the person working on it, this policy is kind of
too crude, giving some regressions particularly at startup when the
application is initializing. Actually trying to base the number of
threads on the amount of copied bytes improves this a lot...

I am talking about this a bit in a recent FOSDEM talk [2].



[1] https://bugs.openjdk.java.net/browse/JDK-8172792
[2] https://fosdem.org/2018/schedule/event/g1/

More information about the hotspot-gc-dev mailing list