JDK-8048180 : G1: Eager reclaim of humongous objects with references
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-06-26
  • Updated: 2025-10-21
  • Resolved: 2025-10-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 b20Fixed
Related Reports
Blocks :  
JDK-8342382 - Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization
Duplicate :  
JDK-8073288 - Eager reclaim non-objArray humongous objects with references
Relates :  
JDK-8368959 - G1: IHOP calculation selects very low threshold and stays there
Relates :  
JDK-8369556 - G1: Lift restriction on eager reclaim of self-referential non-typeArrays
Relates :  
JDK-8027959 - Early reclamation of large objects in G1
Relates :  
JDK-8073288 - Eager reclaim non-objArray humongous objects with references
Relates :  
JDK-8058801 - G1TraceReclaimDeadHumongousObjectsAtYoungGC only prints humongous object liveness output when there is at least one candidate humongous object
Sub Tasks
JDK-8369988 :  
Release Note: Eager Reclaim of Humongous Objects with References for G1 - Open
Description
JDK-8027959 introduces early reclamation of large non-reference array objects.

This limitation has shown to not be of concern as large reference arrays tend to be long-lived in the applications this has been tested for - that proves to be wrong in some applications.

Investigate impact and usefulness of extending this feature to reference array objects.
Comments
Changeset: f292d7c6 Branch: master Author: Thomas Schatzl <tschatzl@openjdk.org> Date: 2025-10-13 14:51:08 +0000 URL: https://git.openjdk.org/jdk/commit/f292d7c66c6279f929eb37ffcc1857a269f72e3d
13-10-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/27525 Date: 2025-09-26 11:53:50 +0000
27-09-2025
A benchmark that improves with this change is Optaplanner, benchmark 4, see attached graph.
21-03-2025
Patch enabling eager reclaim of reference objects outside of marking
21-10-2015
One could enqueue a large objArrayOop to be scanned for references and put them onto the mark stack. It would also be nice to somehow clean up references from this region to other regions at this point. Actually the other remembered sets contain the locations that need to be scanned for live objects (so you might not need to check the entire objArrayOop). Also, large objects referencing each other cannot be handled (easily) as they keep themselves alive via the remembered sets. However, the early reclaim mechanism should be seen as something for picking low-hanging fruits, not a replacement for the global marking, so this might not be relevant.
04-02-2015
Comment from Kim Barrett that must be considered when implementing this: > Here's a specific [problematic] scenario: > > - O1 and O2 are ordinary objects in the same region R, which is an old > generation region. > - H is a humongous object. > - O1 is reachable, and has been scanned. > - O2 is only reachable via H. > > 1. O2 is read from H and stored into O1. > 2. H becomes unreachable. > 3. Evacuation pause eagerly reclaims H. The simplest workaround would be to disable eager reclaim of reference arrays during marking. Marking end will reclaim them "soon" anyway. This would lower the effectiveness of the technique though.
04-02-2015