JDK-8191117 : [Nestmates] Update JNI, JVM TI and JDI/JDWP to allow for nestmate access
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: repo-valhalla
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-11-13
  • Updated: 2018-05-29
  • Resolved: 2018-05-29
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.
Other
repo-valhallaFixed
Related Reports
Relates :  
Description
Need to update specifications to allow access where needed.

Need to check we can invoke private nestmate methods, and access fields etc.

Need to check virtual vs non-virtual invocations modes.

Tests for the above (mirroring those already done for direct member accesses).
Comments
Changeset: 3234088eb2d2 Author: dholmes Date: 2018-05-28 21:09 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/3234088eb2d2 8191117: [Nestmates] Update JNI, JVM TI and JDI/JDWP to allow for nestmate access Reviewed-by: mainline RFR + test/hotspot/jtreg/runtime/Nestmates/NestmatesJNI.java + test/hotspot/jtreg/runtime/Nestmates/libNestmatesJNI.c + test/hotspot/jtreg/runtime/Nestmates/privateConstructors/TestJNI.java + test/hotspot/jtreg/runtime/Nestmates/privateFields/TestJNI.java + test/hotspot/jtreg/runtime/Nestmates/privateMethods/TestJNI.java + test/hotspot/jtreg/runtime/Nestmates/privateMethods/TestJNIHierarchy.java + test/hotspot/jtreg/runtime/Nestmates/privateStaticFields/TestJNI.java + test/hotspot/jtreg/runtime/Nestmates/privateStaticMethods/TestJNI.java
29-05-2018

I realized that doing JNI tests for nestmates is borderline but doing JDI tests is pointless. Neither JNI nor JDI engage in access control and the calling context is irrelevant to the operation - so in that sense there is no such thing as a nestmate access/invocation when using JNI or JDI. For JNI the tests at least check that it's method lookup and callVirtual/nonVirtual work correctly for private methods, so having gone to the trouble of adding them I propose keeping them (I added them to the RFR yesterday). For JDI when the debugger is running in one VM and the debuggee in another then nothing we do is actually testing anything in relation to nestmates. There is still an issue of selecting the right method, but that's a "private methods" issue, not a nestmates issue - and really there should already be tests for that. And it's not really a selection issue in the regular VM sense, as you get a Method reference and an ObjectReference and you just ask it to invoke the Method with the given ObjectReference as the receiver - choosing either a virtual or non-virtual invocation mode (just like JNI - and in fact JNI is used by the JDWP backend to implement this).
29-05-2018

JNI tests have now been developed and will be incorporated into the mainline RFR.
28-05-2018

I overlooked that JDWP and com.sun.jdi.VirtualMachine support redefineClasses in a similar manner to JVM TI - though no mention of class attributes is explicitly made. That has been handled under JDK-8196311. This issue remains open purely to add JNI and JDI based access tests.
14-05-2018

In summary no specification changes are needed in these areas. All we need are tests using the different API's on nestmates to ensure things work as expected.
09-01-2018

No changes are required to com.sun.jdi.ObjectReference.invokeMethod https://docs.oracle.com/javase/9/docs/api/com/sun/jdi/ObjectReference.html#invokeMethod-com.sun.jdi.ThreadReference-com.sun.jdi.Method-java.util.List-int-
09-01-2018

The JDWP spec requires no updates as it does not enforce access control. https://docs.oracle.com/javase/9/docs/specs/jdwp/jdwp-protocol.html
09-01-2018

I have examined the JVM TI specification and there are no mechanisms for invoking methods, or accessing fields and so no concerns over access control based on the location of the callsite. So no changes needed to JVM TI in that regard. https://docs.oracle.com/javase/9/docs/specs/jvmti.html
09-01-2018

I have examined the JNI specification in detail and it is oblivious to accessibility issues. So there are no specification changes needed for JNI. https://docs.oracle.com/javase/9/docs/specs/jni/index.html
09-01-2018

See JDK-8165827 for related changes when private interface methods were introduced.
09-01-2018

Lumped under runtime for initial nestmate work in valhalla. The actual changes to mainline may need to be split across runtime (JNI), jvmti and serviceability.
13-11-2017