JDK-8267924 : Misleading G1 eager reclaim detail logging
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 11,17
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-05-28
  • Updated: 2025-01-29
  • Resolved: 2021-06-07
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 17
17 b26Fixed
Related Reports
Relates :  
JDK-8268331 - Fix crash in humongous object eager reclaim logging
Relates :  
JDK-8267836 - Separate eager reclaim remembered set threshold from G1RSetSparseRegionEntries
Relates :  
JDK-8268330 - [BACKOUT] JDK-8267924: Misleading G1 eager reclaim detail logging
Description
With gc+humongous (and eager reclaim on) the log output for found live regions looks as follows:

Live humongous region <region-idx> object size <size> start <address>  with remset <cardset-size> code roots <code-roots-size> is marked <is-marked> reclaim candidate <is-candidate> type array <is-type-array>

There are some misleading values in the fields:

<cardset-size> is always "0" at this point because for a long time now we always defer remset updates to the concurrent phase. (It also only contains actual number of references in the remset, not considering outstanding card set entries still to be refined).

<is-candidate> is just wrong and always "false" here as it uses an internal table which entry is intentionally cleared if any reference has been found during gc

Fix this; I think by moving the "Live" messages somewhere else and just making them "humongous object" messages both issues could be fixed.
Comments
Changeset: 15715a89 Author: Thomas Schatzl <tschatzl@openjdk.org> Date: 2021-06-07 13:18:27 +0000 URL: https://git.openjdk.java.net/jdk/commit/15715a8984e3e346c2a65e5a0c7b48c4dee21d3e
07-06-2021
New suggested logging output: First, all humongous regions [0.085s][debug][gc,humongous] GC(4) Humongous region 0 (object size 41943056 @ 0x00000000f8000000) remset 0 code roots 0 marked 0 reclaim candidate 1 type array 1 [0.086s][debug][gc,humongous] GC(4) Humongous region 71 (object size 25165840 @ 0x00000000fc700000) remset 0 code roots 0 marked 0 reclaim candidate 1 type array 1 [0.085s][debug][gc,humongous] GC(4) Humongous region 41 (object size 4194320 @ 0x00000000fa900000) remset 0 code roots 0 marked 0 reclaim candidate 1 type array 1 [0.085s][debug][gc,humongous] GC(4) Humongous region 46 (object size 25165840 @ 0x00000000fae00000) remset 0 code roots 0 marked 0 reclaim candidate 1 type array 1 Later only reclaimed ones. [0.086s][debug][gc,humongous] GC(4) Reclaimed humongous region 46 (object size 25165840 @ 0x00000000fae00000) There is no point in printing out the reasons for the reclamation again: remsets are always zero for reclaim candidates (and only they will be considered for reclamation anyway), code roots will not change as we do not do code unloading or similar, the mark will not change either, reclaim candidate will be zero as indicated in the description, and the type won't change. So there is no information gain in printing these properties.
02-06-2021
This is a logging only issue.
28-05-2021