Baking a 4TB limit into new GC code seems... unwise.
(Graal work for SPARC seemed to have stopped as well)
Is there anyone who can clarify?
- Shenandoah uses Brooks-style forward pointers whereas ZGC uses colored pointers and off-heap forwarding tables.
- Shenandoah could in theory run on Windows, AFAIK this is a non-goal for ZGC.
- Shenandoah tries to return unused heap to the OS wheres currently the recommendation for ZGC seems to be -Xms == -Xmx. In addition ZGC tripple maps the heap which can lead to interesting challenges in resource usage accounting.
- None of them are generational although Shenandoah allows for custom policies.
- Both of them seem to disable biased locking by default. I would guess the latency for deoptimizing is simply too large.
- Shenandoah supports pinning objects in JNI criticals without disabling the GC.
- Somewhat unsurprisingly ZGC introduces several HotSpot latency optimizations that will also benefit Shenandoah (thread-local handshakes, concurrent reference processing, ...).