RFR 8042235: redefining method used by multiple MethodHandles crashes VM

[Coleen Phillimore]

On 11/19/14, 8:13 AM, Lois Foltan wrote:
> Hi Coleen,
>
> I think this looks good and I actually like the implementation better 
> than the former indexing approach.  One minor comment:
>
> src/share/vm/prims/methodHandles.cpp
>   - line #278 if statement conditional, the expression 
> "m->method_holder()" could be changed to "m_klass"
>     which is set at the top of the routine to contain 
> m->method_holder().  m_klass seems to be used
>     consistently in that manner throughout the routine. \

m_klass is a stupid KlassHandle so I'd have to upcast it to 
InstanceKlass but method_holder() returns the right type InstanceKlass 
so I now think m->method_holder() is better.

I should get back to work deciding whether we can remove these 
KlassHandle types....

Thanks!
Coleen

>
> Lois
>
> On 11/17/2014 5:49 PM, Coleen Phillimore wrote:
>> Summary: note all MemberNames created on internal list for adjusting 
>> method entries.
>>
>> The JVM MemberNameTable code will push all member names on the list 
>> rather than trying to index by method_idnum.  The code to look up 
>> MemberName types wasn't used so was removed.  Class redefinition 
>> iterates through the table sequentially to update the Method* 
>> pointers in saved member names.
>>
>> This change will work with David Chase's change to the Java code for 
>> bug 8013267 without the extra code dealing with class redefinition.
>>
>> Tested with vm.quick.testlist, jck tests and jtreg tests, including 
>> the mlvm tests that failed in the bug report.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8042235/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8042235
>>
>> Thanks,
>> Coleen
>