JDK-6227506 : JVMTI Spec: Atomicity of RedefineClasses should be specified
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2005-02-09
  • Updated: 2021-08-24
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
tbdUnresolved
Related Reports
Relates :  
JDK-8151546 - nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly
Relates :  
JDK-8155951 - VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool
Description
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
Comments
Because of JDK-8155951 (constant pool merging doesn't include cpCache merging) there's an implicit lock around each class that is being redefined so that two threads cannot try to redefine the same class at the same time. The prologue code waits on the RedefineClasses_lock until all the classes specified are not currently being redefined. This is for the code that runs before the redefinition safepoint. I don't know how this fits into the specification but it seems like a really good thing to do,
24-08-2021
David, I'm pretty sure the implementation follows this spec statement in general. It is a bug if there is a context where the implementation misses to do it. Changing it to be an enhancement.
24-08-2021
To the first point, the spec already states: "If any error code is returned other than JVMTI_ERROR_NONE, none of the classes to be redefined will have a new definition installed." I don't know if the implementation actually does that.
13-02-2018
A big preparation work is done in the VM_RedefineClasses::doit_prologue(). A set of static variables used there must be protected from MT access. Also, it seems to be a right approach to disallow multiple simultaneous class redefinitions even if they do a preparation work.
19-06-2014
This seems to be looking for transactional semantics more than mutual exclusion. If this is a safepoint op it is unclear what the additional locking achieves.
19-06-2014
Thomas's patch adds a lock which seems good. Make sure there are no performance or specification problems with it. VM_RedefineClasses op(class_count, class_definitions, jvmti_class_load_kind_redefine); { MutexLocker sd_mutex(RedefineClasses_lock); VMThread::execute(&op); } return (op.check_error());
18-06-2014