Request for review: 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9
jiangli.zhou at oracle.com
Mon Jan 7 15:26:18 PST 2013
On 01/07/2013 02:32 PM, Coleen Phillimore wrote:
> 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>
>>> Please review the fix for 8001341/8004223: SIGSEGV in
>>> hs24 webrev:
>>> jdk8 webrev:
>>> 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