RFR JDK-8181425: Reflection API defend against issues with internal VM derived value type

Mandy Chung mandy.chung at oracle.com
Fri Jun 23 22:49:47 UTC 2017


Hi Tobias,

Thanks for looking into the issues.

> On Jun 23, 2017, at 5:32 PM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> Hi Mandy,
> 
> as I mentioned off-thread, this change breaks the ValueTypeTestBench.java because we rely on MyValue1.class.getDeclaredMethods() [1] to be able to access the declared methods of a value type and set compilation and inlining rules via the Whitebox API. This is crucial for the tests to work. In this case the value type is not derived but it's an VVT declared with "__ByValue”.

I add a property “jdk.lang.reflect.DVT” to allow reflection on DVT,
as Maurizio suggests.  When ValueTypeTestBench.java is converted to
use VCC/DVT and do reflection on VCC, we should remove this property.

> This change also breaks the ValueTypeArray.java test with:
> Caused by: java.lang.ClassNotFoundException: [Qruntime.valhalla.valuetypes.Point; is a derived value class
> 	  at java.base/java.lang.Class.forName(Class.java:293)
> 

This attempts to load DVT array class.  Can the test use ValueType::arrayValueClass?  I comment out testClassForName test case.
Do you mind updating the test to use ValueType::arrayValueClass instead?


> This is a problem with the C2 intrinsic for java.lang.Class::isAssignableFrom which does not work properly with value types. I'll work on a fix. As temporary workaround you can use -XX:DisableIntrinsic=_isAssignableFrom.
> 

Another workaround is to check for ACC_VALUE for now and avoid
calling isAssignableFrom until this issue is fixed.

Here is the updated webrev:
 http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8181425/webrev.03/


Mandy



More information about the valhalla-dev mailing list