Description
The Graal compiler currently does not support the Hotspot Shenandoah GC. Shenandoah GC is relevant in situations where latency is a concern, because it drastically reduces GC pause times. This is not only relevant in large-heap settings where GC tends to take a long time due to the size of live data that needs to be marked and relocated, but also in resource-constrained environment where even relatively little STW-work can balloon.
A first step in supporting Shenandoah GC in Graal compiler would be to implement the basic Shenandoah barriers:
- Load-reference barrier to be employed after loading references
- SATB-barrier to be employed before reference writes (very similar to G1's SATB barrier)
- CAS-obj barrier that handle Unsafe.compareAndSwapReference() and related methods
- Arraycopy barrier to deal with arraycopies of Object[]
- Reference.get() barrier
This would be enough to support Graal compiler in JDK 11. However, additional features have been added between JDK 11 and JDK 17, which require extra work:
- Concurrent class-unloading requires so-called nmethod-barriers: little pieces of GC code to be called when calling into 'armed' nmethods (and a mechanism to arm nmethods).
- Concurrent thread-scanning which requires stack-watermark support.
Both these features are not Shenandoah specific. For example, ZGC would also make use of them.
Much of the first step (JDK 11 support) is implemented in #2426.