Request for review: 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9
coleen.phillimore at oracle.com
Mon Jan 7 14:32:54 PST 2013
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:
>> 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:
> 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.
> -- Chris
>> Tested with -XX:+CheckUnhandledOops on solaris (x64) using vm.quick.testlist. Tested with jprt.
More information about the hotspot-runtime-dev