JDK-6929027 : Bootstrap and target methods handles are not invalidated when class is redefined via JVMTI
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs24,hs25
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2010-02-23
  • Updated: 2013-03-27
  • Resolved: 2013-03-27
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.
JDK 8
8-poolResolved
Related Reports
Duplicate :  
Description
Bootstrap and target methods currently can't be redefined inside those methods.

Consider the following scenarios:

A:

1. An invokedynamic instruction is executed against some class
2. When it calls bootstrap method, the class is redefined via JVMTI RedefineClasses() function and PopFrame() is called to replace the current (obsolete) bootstrap method with a redefined version

B:

1. An invokedynamic instruction is executed against some class
2. It calls bootstrap method, which creates a CallSite with some target method inside the class
3. When target method is called, the class is redefined via JVMTI RedefineClasses() function and PopFrame() is called to replace the current (obsolete) method with a redefined version

In the both cases, the redefined version of the bootstrap or the target method is never called after PopFrame() for a given call site. But if these old methods calls the other methods of the class, the redefined versions are invoked.

This behavior is not consistent with the JVMTI spec:

"Redefinition can cause new versions of methods to be installed. Old method versions may become obsolete The new method version will be used on new invokes. If a method has active stack frames, those active frames continue to run the bytecodes of the original method version. If resetting of stack frames is desired, use PopFrame to pop frames with obsolete method versions."

Comments
Closing this CR as a dup of the 8008511. The fix of 8008511 is in the open review now so that it is better to keep it and close this one as a dup. Please, let me know if there are any problems with it.
27-03-2013

This is a VM issue, so that I've replaced the "Affects Version's" field values with the hs24 and hs25.
27-03-2013

EVALUATION This needs to be fixed. Inside the JVM it is another form of invalidation. For the user, it is an important "hook" for rerunning code. *** (#1 of 1): 2010-12-21 17:33:25 EST ###@###.###
02-04-2012

EVALUATION This needs to be fixed. Inside the JVM it is another form of invalidation. For the user, it is an important "hook" for rerunning code.
21-12-2010