JDK-8131932 : Ergonomics oversize number of GC threads for small JVMs on large systems
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2015-07-20
  • Updated: 2019-02-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-6858051 - Create GC worker threads dynamically
Description
Description from filer:

We are running a small Java-based monitoring agent for performance monitoring of a database on an M7 system with 2688 cpus. The JVM is configured with a 2 GB heap. Per default, the JVM creates 1682 parallel GC threads. It seems, HotSpot Ergonomics are purely based on the cpu count of the system, but not the JVM size. Such a large number of GC threads is completely unreasonable for a JVM with only 2 GB of Java heap.

As a result, young GC times are in the range of about 3 seconds, with 4000 (!) cpu seconds consumed per GC. When manually configuring the number of GC threads to 64, GC times are reduced to around 0.05 seconds with 1-2 cpu seconds consumed.

On average, this JVM only consumes about half a cpu (out of 2688 cpus) when using 64 GC threads, and its garbage collections have no effect on the overall system. However, with the default of 1682 GC threads, the spikes in CPU utilization during garbage collection drive overall cpu utilization from 20% (average) to 80% (peak), heavily disturbing the database running on this system.

Many Java applications aren't meant for highest performance, but only provide supplementary tasks (such as this monitoring agent). Java Ergonomics should come up with a reasonable default sizing of these JVMs. The total configured Java heap size could serve as an indication as to how many GC threads may at most be necessary.
Comments
(I would argue that there is a workaround in setting the number of worker threads, but you could also argue that the impact is high, since this is a "red-face" issue. It is clearly not a good idea to spawn 1600 threads on a 2GB heap. In any case, it should be a fairly safe fix, at least if we only impact some kind of maximum number of threads)
14-12-2015