JDK-8139800 : Remove OopsInGenClosure
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-10-16
  • Updated: 2024-11-20
  • Resolved: 2020-08-31
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 16
16 b14Fixed
Related Reports
Relates :  
JDK-8072809 - Further cleanups after Generation array removal: gen_process_roots and OopsInGenClosure::set_generation
Relates :  
JDK-7036837 - cardtable interface and class hierarchy simplification
Description
It may be that widespread knowledge of OopsInGenClosure can be reduced or eliminated, possibly even to the point of eliminating the class entirely.
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/c871ea8d4993 User: stefank Date: 2020-08-31 09:04:41 +0000
31-08-2020
In fact, in JDK-8072809 Jesper is proposing to replace almost all calls of set_generation with an assert_generation that asserts that the generation is in fact the one passed in the constructor. There are two cases in MarkSweep where the closures are statics and cannot get their generation from a constructor but that is a minor issue in my opinion. After we are comfortable that the assertions don't fire we can remove almost all external knowledge of the oops in gen closure.
19-10-2015
Kim Barrett: One of the things I found disturbing about MetadataAwareOopsInGenClosure is that, while it’s an OopsInGenClosure, it wasn’t at all obvious where it got its generation from, and since it wasn’t via a constructor argument, the ExtendedOopClosure base class constructor with a reference processor argument obtained from the generation was not being used. And hence the need to set the closure’s reference processor via assignment in strange places.
16-10-2015
Mikael Gerdin: My thought was that with Jesper's patch splitting gen_process_roots into young_ and old_ variants I believe that - Exposing OopsInGenClosure (and its set_generation method) to the root scanning should not be needed. - In fact all OopsInGenClosures used by the framework collectors only ever need one value set up as the "_gen" and "_gen_boundary" members. If this is properly set in the constructors then we could get rid of set_generation.
16-10-2015
Stefan Karlsson has an old prototype of removing OopsInGenClosure.
16-10-2015