JDK-8274178 : G1: Occupancy value in IHOP logging and JFR event is inaccurate
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9,10,11,12,13,14,15,16,17,23
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-09-22
  • Updated: 2025-11-24
  • Resolved: 2025-11-13
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 26
26 b25Fixed
Related Reports
Relates :  
JDK-8371635 - G1: Young gen allocations should never be considered when comparing against IHOP threshold
Relates :  
JDK-8143220 - Fix documentation of InitiatingHeapOccupancyPercent
Relates :  
JDK-8136677 - Adaptive sizing for IHOP in G1
Relates :  
JDK-8371791 - G1: Improve accuracy of G1CollectedHeap::non_young_occupancy_after_allocation()
Description
After JDK-8136677 and JDK-8143220, "occupancy" for G1 IHOP is now computed by this formula:

region_size * (num_old_regions + num_humongous_regions) + new_humonogous_alloc_bytes

However, in G1IHOPControl::print(), G1AdaptiveIHOPControl::print(), G1IHOPControl::send_trace_event() and G1AdaptiveIHOPControl::send_trace_event(), the occupancy value is G1CollectedHeap::heap()->used(), which includes used bytes in young regions and does not include wasted space in old regions.

I'll sponsor my colleague Jonathan Joo to fix this.
Comments
Changeset: 7d78818a Branch: master Author: Thomas Schatzl <tschatzl@openjdk.org> Date: 2025-11-13 13:55:25 +0000 URL: https://git.openjdk.org/jdk/commit/7d78818ae609461ab830c32c222f15f1cab0d2d4
13-11-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/28175 Date: 2025-11-06 10:33:46 +0000
06-11-2025
Yeah, no immediate plan to work on this, and it can be deferred.
04-11-2025
[~manc][~jjoo]: any plans to fix this for JDK 26? Otherwise we can defer it (or unassign yourselves)
04-11-2025
Thank you! The Oracle GC triage team tends to try to have our open bugs on the current or the next JDK release, so that we always have the bugs in sight for each release. So, I'm going to put Fix Version to 26 and we'll reevaluate check again the next release. (RFEs we tend to put as tbd)
15-05-2025
Apology for neglecting this issue. We are not actively working on this, but hopefully will pick up https://github.com/openjdk/jdk/pull/5762 again when I have time. I changed "Fix Version" to tbd.
15-05-2025
[~manc][~jjoo] Do you have any plans to continue this work? We're going over P4 Bugs in preparation to defer those that we'll not get to before the JDK 25 fork.
12-05-2025