Request for review: 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9

[Coleen Phillimore]

Jiangli, This looks good.

On 01/07/2013 05:34 PM, Christian Thalinger wrote:
> On Jan 7, 2013, at 12:30 PM, Jiangli Zhou <jiangli.zhou at oracle.com> wrote:
>
>> Hi,
>>
>> Please review the fix for 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9.
>>
>> hs24 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_hs24.00/
>> jdk8 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.00/
>>
>> The SIGSEGV was caused by an unhandled methodOop in methodOopDesc::fast_exception_handler_bci_for() and JvmtiExport::post_exception_throw(). It's only reproducible on hs24 as oops in the perm-gen could be moved by the GC. The bug was not reported on jdk8. On jdk8, Method* doesn't move. However the fix is still needed on jdk8 since the Method* in JvmtiExport::post_exception_throw() could be redefined after the  methodOopDesc::fast_exception_handler_bci_for() call. The handle will keep it from being deallocated.
> I was just going to say it's not required for HS25 but the redefinition is a valid point.  Although imperceptible.  Could we add a comment in:
>
> src/share/vm/oops/method.hpp
>
> to prevent someone undoing this change?

Yes, this is sort of unfortunate because of redefine classes.   The 
methodHandles that we used for oops because methodOop could move, are 
still needed for Method* because they can be deallocated.

thanks,
Coleen

> -- Chris
>
>> Tested with -XX:+CheckUnhandledOops on solaris (x64) using vm.quick.testlist. Tested with jprt.
>>
>> Thanks,
>> Jiangli