JDK-8186777 : Make Klass::_java_mirror an OopHandle
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-08-25
  • Updated: 2019-05-22
  • Resolved: 2017-10-03
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 10
10 b31Fixed
Related Reports
Duplicate :  
JDK-8173988 - Unsafe usage of ClassLoaderData::_handles with CMS
Relates :  
JDK-8193053 - jvm crash by G1CMBitMapClosure::do_addr
Relates :  
JDK-8080852 - Java heap dump doesn't contain klass mirror objects unless they are explicitly referenced
Relates :  
JDK-8188785 - CCP sets invalid type for java mirror load
Description
If the _java_mirror is indirect and stored in the ClassLoaderData::_handles block, the GC will not have to pointer chase ClassLoaderData::_klasses to find the mirror oop, and save time and code.
Comments
Nevermind, Doug already took care of it.
04-11-2017
Changes in src/jdk.internal.vm.compiler need to be pushed to upstream Graal, otherwise they could get lost in the next Graal --> hotspot update. They would have been lost by JDK-8187438, but I merged the changed by accident. The normal Graal update process is to copy Graal code unmodified.
04-11-2017
This change introduced a problem in C2 (see JDK-8188785). I'm investigating.
19-10-2017