RFR: 8305403: Shenandoah evacuation workers may deadlock

William Kemper wkemper at openjdk.org
Thu Apr 13 17:07:40 UTC 2023


On Sat, 8 Apr 2023 02:04:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Given that I can't remember why we (I) did the complex transition in the first place, let's get rid of it and see what explodes (if anything). There's good chances that the original reasons are no longer relevant. We might even consider a more aggressive approach, see my comments (your call).
>
>> Given that I can't remember why we (I) did the complex transition in the first place, let's get rid of it and see what explodes (if anything). There's good chances that the original reasons are no longer relevant. We might even consider a more aggressive approach, see my comments (your call).
> 
> I did not follow the recent development closely. IIRC, the original reason for this complicated dance is that, if a thread encounters evacuation OOM and enters here, it needs to wait all other threads to exit EVAC OOM critical sections, before it can proceed, since another thread may evacuate the same oop successfully, therefore, this thread has to read forwarding pointer on its way out.

@zhengyu123 - The code that is meant to suspend threads when they oom-during-evac is still there. That protocol would take over _after_ the evacuating thread has cancelled the GC.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13309#issuecomment-1507306165


More information about the hotspot-gc-dev mailing list