Bug ID: JDK-8072598 G1 may incorrectly try to reclaim humongous non-Array objects containing references

Versions (Unresolved/Resolved/Fixed)

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 9
9Resolved

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.
16-04-2015
This was fixed as part of the fix for JDK-8069367.
16-04-2015
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)
11-02-2015
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.
05-02-2015
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
05-02-2015

Blocks :	JDK-8077383 - Re-enable eager reclaim by default
Duplicate :	JDK-8069367 - Eagerly reclaimed humongous objects left on mark stack
Relates :	JDK-8027959 - Early reclamation of large objects in G1
Relates :	JDK-8069367 - Eagerly reclaimed humongous objects left on mark stack