JDK-8196311 : [Nestmates] Specification changes for class redefinition
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: repo-valhalla
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-01-29
  • Updated: 2018-04-23
  • Resolved: 2018-03-26
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 :  
JDK-8202159 - [Nestmates] JVM TI version update was incomplete
Description
This splits the spec change into a separate task from the implementation so we can proceed with spec approvals and the umbrella CSR.
Comments
Changeset: d8c27468717b Author: sspitsyn Date: 2018-03-26 02:23 -0400 URL: http://hg.openjdk.java.net/valhalla/valhalla/rev/d8c27468717b 8196311: [Nestmates] Specification changes for class redefinition Summary: Actual specification changes for JVM TI, JDWP etc for nestmates Reviewed-by: dholmes ! make/data/jdwp/jdwp.spec ! src/hotspot/share/prims/jvmti.xml ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java ! src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java
26-03-2018
specdiffs for these and future modifications up to mainline integration are here: http://cr.openjdk.java.net/~dholmes/8010319/specs/JDWP/ http://cr.openjdk.java.net/~dholmes/8010319/specs/JVM-TI/ http://cr.openjdk.java.net/~dholmes/8010319/specs/com.sun.jdi/ http://cr.openjdk.java.net/~dholmes/8010319/specs/java.lang.instrument/
19-03-2018
Thanks, David! I've made this typo in the first place. :(
30-01-2018
Typo fixed above.
30-01-2018
JVM TI and java.langinstrumentation: diff -r 58787a1708d2 src/hotspot/share/prims/jvmti.xml --- a/src/hotspot/share/prims/jvmti.xml Wed Jan 24 11:33:18 2018 -0500 +++ b/src/hotspot/share/prims/jvmti.xml Thu Jan 25 09:57:43 2018 -0800 @@ -358,7 +358,7 @@ ]> <specification label="JVM(TM) Tool Interface" - majorversion="9" + majorversion="11" minorversion="0" microversion="0"> <title subtitle="Version"> @@ -7631,9 +7631,11 @@ <eventlink id="ClassFileLoadHook"/> event will be sent. <p/> - The retransformation may change method bodies, the constant pool and attributes. + The retransformation may change method bodies, the constant pool and attributes + (unless explicitly prohibited). The retransformation must not add, remove or rename fields or methods, change the signatures of methods, change modifiers, or change inheritance. + The retransformation must not change the NestHost or NestMembers attributes. These restrictions may be lifted in future versions. See the error return description below for information on error codes returned if an unsupported retransformation is attempted. @@ -7704,6 +7706,9 @@ A retransformed class file does not declare a method declared in the old class version. </error> + <error id="JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_ATTRIBUTE_CHANGED"> + A retransformed class file has unsupported difference in class attributes. + </error> <error id="JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_MODIFIERS_CHANGED"> A retransformed class file has different class modifiers. </error> @@ -7778,9 +7783,11 @@ <eventlink id="ClassFileLoadHook">Class File Load Hook</eventlink> will be sent (if enabled), but no other <jvmti/> events will be sent. <p/> - The redefinition may change method bodies, the constant pool and attributes. + The redefinition may change method bodies, the constant pool and attributes + (unless explicitly prohibited). The redefinition must not add, remove or rename fields or methods, change the signatures of methods, change modifiers, or change inheritance. + The retransformation must not change the NestHost or NestMembers attributes. These restrictions may be lifted in future versions. See the error return description below for information on error codes returned if an unsupported redefinition is attempted. @@ -7855,6 +7862,9 @@ A new class version does not declare a method declared in the old class version. </error> + <error id="JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_ATTRIBUTE_CHANGED"> + A new class version has unsupported different class attributes. + </error> <error id="JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_MODIFIERS_CHANGED"> A new class version has different modifiers. </error> @@ -11739,6 +11749,9 @@ A method in the new class version has different modifiers than its counterpart in the old class version. </errorid> + <errorid id="JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_ATTRIBUTE_CHANGED" num="72"> + A new class version has unsupported difference in class attributes. + </errorid> </errorcategory> </errorsection> @@ -14811,6 +14824,13 @@ - The function may return NULL in the start phase if the can_generate_early_vmstart capability is enabled. </change> + <change date="25 Junuary 2018" version="11.0.0"> + Minor update on new class file NestHost and NestMembers attributes: + - Add new error JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_ATTRIBUTE_CHANGED + that can be returned by RedefineClasses and RetransformClasses + - Clarify that RedefineClasses and RetransformClasses are not allowed + to change the class file NestHost and NestMembers attributes + </change> </changehistory> </specification> diff -r 58787a1708d2 src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java --- a/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java Wed Jan 24 11:33:18 2018 -0500 +++ b/src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java Thu Jan 25 09:57:43 2018 -0800 @@ -219,9 +219,10 @@ * Instances of the retransformed class are not affected. * * <P> - * The retransformation may change method bodies, the constant pool and attributes. + * The retransformation may change method bodies, the constant pool and attributes (unless explicitly prohibited). * The retransformation must not add, remove or rename fields or methods, change the - * signatures of methods, or change inheritance. These restrictions maybe be + * signatures of methods, or change inheritance. The retransformation must not change + * the NestHost or NestMembers attributes. These restrictions may be * lifted in future versions. The class file bytes are not checked, verified and installed * until after the transformations have been applied, if the resultant bytes are in * error this method will throw an exception. @@ -306,9 +307,10 @@ * Instances of the redefined class are not affected. * * <P> - * The redefinition may change method bodies, the constant pool and attributes. + * The redefinition may change method bodies, the constant pool and attributes (unless explicitly prohibited). * The redefinition must not add, remove or rename fields or methods, change the - * signatures of methods, or change inheritance. These restrictions maybe be + * signatures of methods, or change inheritance. The redefinition must not change + * the NestHost or NestMembers attributes. These restrictions may be * lifted in future versions. The class file bytes are not checked, verified and installed * until after the transformations have been applied, if the resultant bytes are in * error this method will throw an exception.
30-01-2018
Found one typo in the jvmti.xsl patch in the following fragment: @@ -7778,9 +7783,11 @@ <eventlink id="ClassFileLoadHook">Class File Load Hook</eventlink> will be sent (if enabled), but no other <jvmti/> events will be sent. <p/> - The redefinition may change method bodies, the constant pool and attributes. + The redefinition may change method bodies, the constant pool and attributes + (unless explicitly prohibited). The redefinition must not add, remove or rename fields or methods, change the signatures of methods, change modifiers, or change inheritance. + The retransformation must not change the NestHost or NestMembers attributes. <== Must be "redefinition", not "retransformation" These restrictions may be lifted in future versions. See the error return description below for information on error codes
30-01-2018
[to @David H.] Ok, I see the reason. Thank you for the explanation!
29-01-2018
I missed some critical specification text in VirtualMachine buried in the @throws: * @throws java.lang.UnsupportedOperationException if * the target virtual machine does not support this * operation. * <UL> * <LI>If {@link #canRedefineClasses() canRedefineClasses()} * is false any call of this method will throw this exception. * <LI>If {@link #canAddMethod() canAddMethod()} is false * attempting to add a method will throw this exception. * <LI>If {@link #canUnrestrictedlyRedefineClasses() * canUnrestrictedlyRedefineClasses()} * is false, attempting any of the following will throw * this exception * <UL> * <LI>changing the schema (the fields) * <LI>changing the hierarchy (subclasses, interfaces) * <LI>deleting a method * <LI>changing class modifiers * <LI>changing method modifiers * </UL> * </UL> So at least we know what restricted means. We might also infer that unrestricted does not really mean "completely unrestricted" but simply that you are allowed to do the things you can't do if restricted. Though these capabilities still seem at odds with what JVM TI permits.
29-01-2018
As this is only for application in the valhalla nestmates branch the actual component/subcomponent is not that significant. We don't want too much overhead. Eventually all the spec changes across all the components will be lumped into one CSR. Thanks.
29-01-2018
The JDWP/JDI and java.lang.instrument do not belong to the subcomponent hotspot/jvmti . The JDWP/JDI is covered by the core-svc/debugger and java.lang.instrument is covered by core-svc/java.lang.instrument. I'm suggesting to split this sub-task to make it more relevant.
29-01-2018
Re: JDWP/JDI I'm a bit concerned by canUnrestrictedlyRedefineClasses - it sounds more capable that JVM TI! But at the same time the docs in JDWP say nothing about modifying attributes. I'm unclear whether the ability to modify attributes was actually intended here? It's all rather vague. The VirtualMachine docs state: boolean canUnrestrictedlyRedefineClasses���() Determines if the target VM supports unrestricted changes when performing class redefinition. But that is far too broad - it would have to always return false as some redefinition changes simply can't be permitted. ?? The redefineClasses method states: "Use canUnrestrictedlyRedefineClasses() to determine if the redefinition can change the schema, delete methods, change the class hierarchy, etc." which is somewhat less open-ended, except for the fact it ends with etc. I have to think this is just a case of a very poorly worded specification. The spec is very old and the wording in JDWP/JDI is very similar to the old JVMDI spec: http://www.oracle.com/technetwork/java/javase/jvmdi-spec-135507.html#RedefineClasses I'm unclear whether JDWP/JDI should be building on the spec for JVM TI.
29-01-2018
On 29/01/2018 11:16 PM, Daniel D. Daugherty wrote: > > + that can be returned by RedefineClasses and RetransforClasses > > + - Clarify that RedefineClasses and RetransforClasses are not allowed > > s/RetransforClasses/RetransformClasses/ > > > + * the NestHost or NestMembers attributes. These restrictions maybe be > > + * the NestHost or NestMembers attributes. These restrictions maybe be > > s/maybe/may/ > > Typo in the original (twice), but please fix. Fixed in the above.
29-01-2018