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

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Tue Apr 2 17:07:30 PDT 2013


Hi Coleen,

Again, thank you a lot for reviewing this code!

This is a good catch too, thank you for pointing to it.
BTW, I was thinking that this probably must be explicitly
deallocated but at some point lost my focus. :)

Thanks!
Serguei


On 4/2/13 3:45 PM, Coleen Phillimore wrote:
>
> Hi Serguei,
>
> This looks good from how much I understand of these two things. There 
> is one problem that I found though.  In 
> ConstantPool::extend_operands() and shrink_operands() when you 
> allocate a new Array<u2>* and assign it to the from_cp, you have to 
> explicitly deallocate the operands that were there with 
> MetadataFactory::free_array<u2>() or they will leak.  This isn't true 
> if you backport this code to 7u.
>
> Thanks,
> Coleen
>
> On 03/27/2013 07: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/20130402/870a2e6a/attachment.html 


More information about the serviceability-dev mailing list