JDK-8072598 : G1 may incorrectly try to reclaim humongous non-Array objects containing references
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8u40,9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2015-02-05
  • Updated: 2015-04-16
  • Resolved: 2015-04-16
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.
Related Reports
Blocks :  
Duplicate :  
Relates :  
Relates :  
In JDK-8027959 G1 introduced early reclaim for humongous objects that have no references.

The check whether a humongous object has no references is performed whether the object is not an object array.
This automatically exclude those.

However it is possible that regular non-array objects are humongous: while there is a limit on the number of members of a particular class, subclasses may be larger. That means that regular objects can be humongous.

Which is a problem because regular objects may contain references that might be missed if they are reclaimed during a concurrent marking cycle.
Reopened and closed as duplicate to indicate that there is no separate changeset to be expected here.

This was fixed as part of the fix for JDK-8069367.

A more inclusive fix (that includes humongous regular objects without any references in the Java object would be something like: can_potentially_reclaim = obj->is_typeArray() || (obj->is_instanceOop() && ((instanceOop*)obj)->nonstatic_oop_map_size() == 0)

Proposed fix: Do not use !is_objArrayOop in the humongous reclaim candidate selection, but is_typeArray() which is more specific. It might be a good chance to introduce a more generic "has_references()"/"contains_references()" getter in oopDesc that subsumes all this. There might be various places in the GC code that use !is_objArrayOop() but wanting exactly that. This might be an extra CR.

Preliminary ILW: Impact: high - crash Likelihood: low - needs java objects that are humongous, i.e. with > 1/2 region size. Generated code may have that property. - that java objects need to be unreferenced during marking cycle - marking cycle must be running - the object referenced by this humongous object must be the only one reference to that object (In fact, we have never encountered such a case so far: the possibility has been pointed out by ~kbarrett; taken all this together, I am using low as likelihood, but it might be medium) Workaround: medium - disable early reclaim at the cost of some performance (for applications that use many large objects); this can be somewhat mitigated by increasing heap region size (that will also decrease the existence of such large objects). HLM->P3