RFR: 8305403: Shenandoah evacuation workers may deadlock

[William Kemper]

On Mon, 3 Apr 2023 23:59:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 337:
>> 
>>> 335:           "end of concurrent marking.")                                     \
>>> 336:                                                                             \
>>> 337:   product(bool, ShenandoahSuspendibleWorkers, true, EXPERIMENTAL,           \
>> 
>> Can we provide some more information under help as to why workers should or should not be suspendible?
>
> I would like to know this myself ;) There are phases of class unloading that unconditionally suspend the control and worker threads. It's not clear to me why marking or evacuation threads would need to suspend.

There is a discussion of this feature in the archives: https://mail.openjdk.org/pipermail/shenandoah-dev/2017-May/002559.html

It seems that suspending worker threads is intended to avoid interfering with other safepoint operations that might not behave well if objects are being moved around the heap. I believe the flag was enabled by mistake when concurrent class unloading was implemented (concurrent class unloading unconditionally participates in STS and does not read this flag). That being said, this has been the default behavior for many years and - apart from this deadlock - I can see no reason for turning it off. That discussion is many years old now and many changes around full GC and code cache scanning/sweeping have transpired. As @rkennke said:

> There's good chances that the original reasons are no longer relevant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13309#discussion_r1167185840