JDK-8137159 : [JVMCI] CompilerToVM::getConstantPool method does not work according to javadoc
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-09-25
  • Updated: 2017-08-04
  • Resolved: 2015-09-28
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
9Fixed
Related Reports
Relates :  
JDK-8062493 - JEP 243: Java-Level JVM Compiler Interface
Relates :  
JDK-8138581 - [JVMCI] CompilerToVM::getConstantPool method does not work according to javadoc after fix of JDK-8137159
Description
CompilerToVM::getConstantPool method does not work according to javadoc.

Javadoc says: "If the base object is a MetaspaceWrapperObject then the metaspace pointer is fetched from that object and used as the base. Otherwise the object itself is used as the base."

If we look in the native code of this method (http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/file/d511f93727fc/src/share/vm/jvmci/jvmciCompilerToVM.cpp#l301), we see that no other Objects except three (HotSpotResolvedJavaMethodImpl, HotSpotConstantPool, HotSpotResolvedObjectTypeImpl) may be used for input.

So we cannot use a custom implementation of MetaspaceWrapperObject interface.

Javadoc should be corrected.

Javadoc should say that no other object except instances of (HotSpotResolvedJavaMethodImpl, HotSpotConstantPool, HotSpotResolvedObjectTypeImpl) and null can be used as input, or java.lang.IllegalArgumentException will be thrown.
Comments
was fixed is project repo, verified as part of integration testing.
04-08-2017
it's not really resolved, please see JDK-8138581
30-09-2015
http://hg.openjdk.java.net/graal/graal-jvmci-9/hotspot/rev/cb448d8f764a
28-09-2015
https://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-8/rev/e8f298580f99
28-09-2015
And while we could call down to invoke MetaspaceWrapperObject.getMetaspacePointer, that's kind unpleasant overhead for a field read, though it would be simple. We could simply document that there are only a fixed set of MetaspaceWrapperObjects known to the JVM and any other subclasses are rejected with an exception. Not an obvious good looking solution.
28-09-2015
That would certainly be preferred but the inheritance hierarchy of the wrapper types makes that a bit unappealing. They all have multiple superclasses that are not wrapper objects.
28-09-2015
Another way to solve this is making MetaspaceWrapperObject an abstract class w/ one field to store a pointer, and use this field in HotSpotResolvedJavaMethodImpl, HotSpotConstantPool, HotSpotResolvedObjectTypeImpl. this will also make C++ simpler -- read from one field regardless the type of 'base' object.
27-09-2015
I don't think that we have to fix the javadoc, another solution would be updating implementation to work w/ any MetaspaceWrapperObject and just call MetaspaceWrapperObject::getMetaspacePointer():J
26-09-2015
Please provide the similar javadoc changes for CompilerToVM::getResolvedJavaType and CompilerToVM::getResolvedJavaMethod methods.
25-09-2015