JDK-8229410 : Unnecessary GCLocker-initiated young GCs
  • Type: Backport
  • Backport of: JDK-8048556
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8u221
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-08-12
  • Updated: 2021-02-08
  • Resolved: 2019-08-12
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.
JDK 14 JDK 8
14Fixed 8u221 b35Fixed
The above mentioned bug says about intermittent failure. But this is a consistent failure on G1 GC, because G1GC logs don���t match with the pattern it is expecting. This is how the log comes from other GC : [GC (GCLocker Initiated GC) [PSYoungGen: 251616K->8192K(252416K)] This is how the log comes in G1 GC : [GC pause (GCLocker Initiated GC) (young), 0.0044442 secs] In second case, there is no close chance also to get match with the pattern : private static final String ANY_LOCKER = locker + ��� [1-9][0-9]{5,6}K���; private static final String BAD_LOCKER = locker + ��� [1-9][0-9][0-9][0-9][0-9]?K���; Because clearly the pattern is looking for a size or a size reduction. How SQE can be assured that this is not a source issue and a test issue ? Do, you have any other test which can verify the issue. Also, we felt that the number of GCLocker initiation should be lesser after the fix, which is true for ParallelGC but that is not the behavior we are seeing in G1GC. Is that not evident ?

The test case need to be problem listed in 8u also as part of https://bugs.openjdk.java.net/browse/JDK-8229156 The issue is only with the test case and not with the fix patch. It has been identified that, this test case is hard to fix for G1GC.