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

[serguei.spitsyn at oracle.com]

Resending this request because the webrev link below is incorrect.
It is correct as you see it but its reference is incorrect when you click.

This is a correct link (safe to click):
http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8007037-JVMTI-JSR292.1/

Thanks,
Serguei


On 3/27/13 4:45 PM, serguei.spitsyn at oracle.com wrote:
> 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/20130401/12db784b/attachment.html