hs25 review request: 8007037 JSR 292: the VM_RedefineClasses::append_entry() should do cross-checks with indy operands (original) (raw)

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Wed Mar 27 16:45:04 PDT 2013

Please, review the hs25 fix below.

Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8007037-JVMTI-JSR292.1/

CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007037 https://jbs.oracle.com/bugs/browse/JDK-8007037

References from INDY bootstrap method specifier operands to CP entries and back must be correctly merged at class redefinition.

Some background.

An invokedynamic bytecode spec: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.invokedynamic

A invokedynamic instruction has an argument which is an index to the Constant Pool item. That index must be a symbolic reference to a call-site specifier: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.4.10

A CP item of the type CONSTANT_InvokeDynamic_inf has an index into the bootstrap method attribute of the class file: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.21

The |BootstrapMethods| attribute elements normally have references to other Constant Pool items.

In VM the bootstrap method attribute is represented by the operands array of the ConstantPool.

The problem is is that all the force and back cross links between ConstantPool elements and operands array elements must be correctly merged at class redefinition.

Test coverage: vm.mlvm, nsk.jvmti, nsk.jdi tests on multiple platforms (32 vs 64-bit too). The testing looks good so far. One difficulty is that new vm.mlvm tests are currently failed because of multiple reasons.

Thanks, Serguei

More information about the hotspot-dev mailing list