RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u

[Roman Kennke]

> Would anyone like to put forward arguments for what makes this
> change necessary?

Let me try.

While Shenandoah GC is certainly not your usual mainstream garbage
collector, it has proven to be very useful for certain use-cases:

- It maintains consistently low pause times, even with large heaps
- It works very well in resource-restricted environments, e.g.
containers or slow hardware (e.g. embedded systems), again with good
latency/low pause times (part of that story is compressed-oops support)
- It is maintained in 11u, which means it receives bug-fixes, and
occasional improvements where they make sense (i.e. don't touch non-
Shenandoah code)

To my knowledge, no other GC in 11u fills that niche. It doesn't seem
to be a small and esoteric niche that almost nobody would use either:
the whole reason why we're offering this for inclusion in JDK11u is
that other major contributors/vendors have asked for it. Originally
that was Amazon and Azul, and recently Microsoft and Alibaba have
voiced their interest too. Martin has sent some more details about
Microsoft's use-case for it, I guess the other vendors would have
similar stories to tell.

My point of view is that it would be in the best interest of JDK11u if
all downstreams would build on the same source base. It seems more
useful if all parties work together on the same 11u mainline tree,
instead of half of the contributors work together on some shared
downstream (e.g. jdk11u-plus or even shenandoah/jdk11), and the other
half on the 'real thing'. I am not sure if such fragmentation would
serve us better overall. I wouldn't think so.

In summary, my points of necessity are:
- Shenandoah fills a void in GC space: large heaps and
container/resource-restricted environments, while maintaining great
latencies
- Avoidance of fragmentation/unnecessary downstream forks

Thanks,
Roman