-
Enhancement
-
Resolution: Unresolved
-
P4
-
6
-
generic
-
generic
The JVMTI spec for RedefineClasses should state something like:
- if an error code is returned (eg, because the redefine
operation failed for one of the classes), then logically,
the VM is in the same state as if the RedefineClasses call had
not occured -ie, none of the other classes specified in the
call have been redefined
- After the first occurance of a call to a method gets to a new version of
the method in a redefined class, all other calls to methods
that have also been redefined will also go to new versions.
IE, it would be illegal if
- the redefine operation changed methods m1 and m2
- the JVMTI implmentation installed the new version of m1
and then let user code execute
- the user code called m1 and got the new version
- a call to m2 then occured and got to the old version instead
of the new version.
###@###.### 2005-2-09 22:48:14 GMT
- if an error code is returned (eg, because the redefine
operation failed for one of the classes), then logically,
the VM is in the same state as if the RedefineClasses call had
not occured -ie, none of the other classes specified in the
call have been redefined
- After the first occurance of a call to a method gets to a new version of
the method in a redefined class, all other calls to methods
that have also been redefined will also go to new versions.
IE, it would be illegal if
- the redefine operation changed methods m1 and m2
- the JVMTI implmentation installed the new version of m1
and then let user code execute
- the user code called m1 and got the new version
- a call to m2 then occured and got to the old version instead
of the new version.
###@###.### 2005-2-09 22:48:14 GMT
- relates to
-
JDK-8155951 VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool
- Resolved
-
JDK-8151546 nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly
- Closed