Shenandoah hangs on specjvm2008 due to reentrant handshake

Zhengyu Gu zgu at redhat.com
Wed May 12 12:40:20 UTC 2021


> 
> Thanks for reporting. Could you please post your fix?
> 
Saw your fix in CR.

Thanks,

-Zhengyu

>>
>> The hanging comes from 
>> https://bugs.openjdk.java.net/browse/JDK-8262443 which
>> introduced the possibility of reentrant handshake and looks like only 
>> shenandoah
>> would hit the scenario. I have a question specific to shenandoah that 
>> why do we
>>   need the phase of "entry_update_thread_roots"?
>> I think we already concurrently relocate the oops in thread roots by
>> "entry_thread_roots".
> 
> entry_thread_roots fixes on-stack frames, but can not prevent thread 
> from loading from-space oops during continuing execution. Ideally, 
> Shenandoah LRB should prevent this from happening, if LRB is "atomic" ( 
> no safepoints between load and LRB), unfortunately, current LRB is not.
> 
>> And "entry_update_thread_roots" doesn't use a general concurrent stack 
>> processing
>> via stack watermark but just a handshake.
> 
> At point we execute entry_update_thread_roots, cset has been completely 
> evacuated, therefore, no more from-space oops in heap. There are very 
> rare cases that threads can still hold stalled oops, can be flushed out 
> very quick, especially, if we can handshake individual Java thread and 
> not cause global safepoint.
> 
> -Zhengyu
> 
>>
>> Thanks,
>> Liang
>>



More information about the shenandoah-dev mailing list