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