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

[serguei.spitsyn at oracle.com]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130327/e2bc57f8/attachment.html