RFR 8054008: Using -XX:-LazyBootClassLoader crashes with ACCESS_VIOLATION on Win 64bit
Jiangli Zhou
jiangli.zhou at oracle.com
Fri Nov 7 22:46:54 UTC 2014
Hi Roland,
On 11/07/2014 09:29 AM, Jiangli Zhou wrote:
> Hi Roland,
>
> Thank you for the review. Please see comments and questions below.
>
> On 11/07/2014 05:16 AM, Roland Westrelin wrote:
>> Hi Jiangli,
>>
>>> Please review the following changes that fix the crash with
>>> -XX:-LazyBootClassLoader on windows x64 platforms (fastdebug only).
>>> During VM initialization, current_stack_pointer() could be called
>>> before the VM generates stub routines. The generated get_previous_sp
>>> routine cannot be used during that time, use the estimated value for
>>> the sp value instead. The x86 implementation is unaffected by the
>>> change and always returns the estimated sp value as before.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8054008
>>> webrev: http://cr.openjdk.java.net/~jiangli/8054008/webrev/
>>>
>>> Tested with JPRT and ExtBadJAR test.
>> But if what os::current_stack_pointer() returns is no longer
>> “accurate”, aren’t you at risk of hitting the assert in
>> os::verify_stack_alignment()? Shouldn’t you skip the assert entirely
>> if the routine is not yet available?
>
> For x64, it still returns the "accurate" value once the routine is
> generated. Before the routine is ready, it gives the estimate, which
> might have the risk of upsetting the assert as you suggested. I have a
> few questions. Have you run into the case where the estimate might
> trigger the assertion on x64? What about x86, why that's not handled
> the same as x64?
Answering my own question, verify_stack_alignment() is a nop on x86.
That's probably why there was no need to obtain the "accurate" previous
sp on x86 and an estimated value was always returned on x86.
>
>>
>> Also why not make that change on all platform to improve robustness
>> while you’re doing this?
>
> Thank you for the suggestion. Sound good. I'll look into this. Is
> there a global flag that indicates the stub routines are generated?
I changed windows os::verify_stack_alignment() to skip the assert when
StubRoutines::code1() is NULL. Please see the following updated webrev.
Regarding you question about other platforms, only windows x64 has this
particular issue. The os::verify_stack_alignment() is nop for sparc,
ARM, and x86. The ppc, linux-x64, solaris-x64 verify_stack_alignment()
implementations do use the generated routine to obtain previous sp.
http://cr.openjdk.java.net/~jiangli/8054008/webrev.02/
Thanks,
Jiangli
>
> Thanks,
> Jiangli
>
>>
>> Roland.
>
More information about the hotspot-runtime-dev
mailing list