JDK-8156587 : [JVMCI] remove Unsafe.getJavaMirror and Unsafe.getKlassPointer
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2016-05-09
  • Updated: 2016-07-07
  • Resolved: 2016-06-07
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
9 b126Fixed
Related Reports
Relates :  
JDK-8022853 - add ability to load uncompressed object and Klass references in a compressed environment to Unsafe
Description
JDK-8022853 added 3 methods to the Unsafe API in order to provide supported entry points for JVMCI to retrieve some VM internal data.  A later implementation change of JVMCI which was required to handle class redefinition properly made 2 of these methods unnecessary:

    public native Class<?> getJavaMirror(long metaspaceKlass);
    public native long getKlassPointer(Object o);

Since these methods only exist in JDK 9 we can, and should, just remove them.
Comments
Looks like we safe : src/jdk/vm/ci/hotspot/UnsafeAccess.java import jdk.internal.misc.Unsafe;
06-06-2016
We have a problem. I merged latest changes from jdk9/hs which comde from jdk9/dev and JDK-8157825 changes removed methods from sun/misc/Unsafe.java including getUncompressedObject(): http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/785ed4d845ad [~dnsimon] Doug, do we still using s.m.Unsafe::getUncompressedObject in JVMCI? Or you getting it from jdk/internal/misc/Unsafe?
06-06-2016
I've updated the webrev to add the @ignore directive, fix GetResolvedJavaTypeTest.java and delete GetKlassPointerGetJavaMirror.java.
06-06-2016
I created separate bug JDK-8158860 to fix tests and assigned to SQE. [~dnsimon] you can simple add @ignore 8158860 to this test in your changes: /* * @test * @bug 8136421 + * @ignore 8158860 * @requires (os.simpleArch == "x64" | os.simpleArch == "sparcv9" | os.simpleArch == "aarch64") * @library / /testlibrary /test/lib * @library ../common/patches
06-06-2016
[~iignatyev] please, help with GetResolvedJavaTypeTest.java
06-06-2016
runtime/Unsafe/GetKlassPointerGetJavaMirror.java could be removed.
06-06-2016
Fixing compiler/jvmci/compilerToVM/GetConstantPoolTest.java and deleting runtime/Unsafe/GetKlassPointerGetJavaMirror.java is easy. I find compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java hard to follow - who can help me with fixing it?
06-06-2016
3 tests have to be fixed because they use these methods: compiler/jvmci/compilerToVM/GetConstantPoolTest.java compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java runtime/Unsafe/GetKlassPointerGetJavaMirror.java
06-06-2016
Sorry for not sending to hotspot-dev. In retrospect, it's obvious I should have included that alias as well in my FRF email.
06-06-2016
ok thanks [~kvn] great.
06-06-2016
Review was sent to hotspot-compiler and I reviewed it. And I will sponsor it.
06-06-2016
Did you run tests on this change? If so you should send out for review to hotspot-dev, get reviews and have someone from the compiler group sponsor the change, to get it checked into the repository. I didn't see the RFR (unless you sent it directly to hotspot-compiler, then that's fine).
06-06-2016
Yes, I initially missed the fact that they have different names in jvm.cpp. I've now found and removed them: http://cr.openjdk.java.net/~dnsimon/8156587/
03-06-2016
The methods are implemented in unsafe.cpp, see the linked bug. Also this is an RFE but it's gone through the FC exception process, so you're good to go.
03-06-2016
As far as I can see, these methods have never been implemented in jvm.cpp so they simply need to be removed from the Java sources.
03-06-2016
I see references to this in the jvmci code or at least indirectly. The compiler group has to remove this if it's really unused. jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotspotMemoryAccessProvider.java etc.
03-06-2016
The point of these functions, I thought was to not have java code know whether oops and klass pointers were compressed, or where the offsets or representation of these things are. Not for redefinition. (?)
02-06-2016