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

[Martijn Verburg]

Hi all,

Appreciate all the excellent points being made here on both sides.  I'll snip some of the long thread and reply to some of Gil's points below which I think speaks to the necessity angle.

________________________________
<snip>

> In the thinking process I am suggesting, the value should only matter
> when a thing rises to a certain level of necessity. Above that level,
> Both risk and value matter. But below it, the value should be ignored,
> and necessity should be the only thing being debated.

> You can certainly use some of the value-building arguments to
> argue for necessity as well, and that is a fine thing to do. It's just that
> "I really like it and would appreciate it being added" arguments
> would obviously not count. Let me show examples of things that
> could make sense to argue for new feature inclusion:

> - E.g. if we could show that without a new collector JDK 11
> will show significant degradation from its current behavior
> on some new, here, or obviously coming hardware configurations,
> that could move this subject into the "gut-wrenching" mode I
> talk about earlier in the thread.
> [Sort of where TLS 1.3 is for 8u. Sort of where my thinking about
> aarch64 for 8u is.]

Putting on my Microsoft Hat - we have several 1st and 3rd party users that fall into this category.

They're currently being forced to use an expensive architectural workaround or moving off the JVM altogether because
there isn't a Garbage Collector in for Hotspot in Java 11 that can manage their mission-critical workloads.

They also are unable to migrate to newer versions of Java because the libraries, frameworks, and tooling that they utilize
have in a lot of cases only just managed to get to Java 11 compatibility and it may be several years before they see
support for the tip (leading to 17).

Now, this is clearly a single data point from a single cloud vendor, but this does represent many end users. As another data point, before being
acquired by MSFT we also saw several customers at jClarity with similar challenges from about 2015 onwards.  Indeed, we built a whole business
around using tooling/ML to try and configure the existing 11 collectors for these users ��.  There was a wide range of types of applications that this
impacted, across all industry sectors.

There was a not-insignificant cost to the customer for using a solution like ours, plus all the time and effort investigating and making changes.
Sometimes it just simply wasn't possible and so we'd work with that customer to either re-architect their application (ouch!) or recommended a
non-Hotspot JVM that could cope (Zing being the prominent one of those).

> - E.g. if we identified some dramatic and degenerate
> performance issue that is popping up in some newly common
> field situations (e.g. logging, containers, cloud functions or KNative)
> and can be addressed technically, it may cross into a necessity.

Without going into customer specifics, we see two major use cases that we see as common which are causing serious pain for users today and have been for several years now.

- One is the 'chain of microservices' pattern, where each individual JVM service needs to be tuned to have the smallest, less frequent
pauses possible for the end to end transaction to meet its SLA.

- The other is Big Data - we're seeing some stupendously sized heaps that need supporting, G1 is pretty darn good, but starts to struggle at that scale.

<snip>

> There are obviously lots of other examples possible for necessary
> feature inclusion. My point is that the argument for and against them
> should be framed around what makes them necessary, not what
> makes them valuable or low risk.

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

Hopefully, a couple of data points I mentioned above helps.  Again, it's just from my jClarity/MSFT experience
so, YMMV, but I do feel they are industry trends that are not going away and so I believe this passes the necessity test.

<snip>

I'll add that I'm glad we can have these reasoned discussions in this community, it's a strength of OpenJDK that we do so.

Cheers,
Martijn