...

[Roman Kennke]

> > assuming deep review and other careful measures, as for the JFR 8u
> > backport. So we are focusing on the reward side.
> 
> Sure. Some are focusing on the reward. I argue the rewards doesn't
> matter
> in an already-out LTS.
> 

How is the JFR backport any different, though? One major vendor
included it in their commercial offering. Other vendors wanted to
include it too, in an 8u LTS that was arguably much longer down the
path of stabilization. There was nothing broken in OpenJDK 8u as it
was, that needed fixing IMO. It would have been just as reasonable to
tell users who want JFR in their JVM to use a later LTS instead. And it
came with very considerable risks, I'd argue with much higher risk than
adding Shenandoah, because it required hooks and changes all over the
VM. Why is it treated different, then? What qualifies JFR as necessity
that justifies taking such high risk in such a mature and stabilized
release? Why didn't we have this discussion back then?

> > BTW, we were under the impression that Azul fully supports the idea
> > of backporting Shenandoah.
> > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009808.html
> 
> As I noted elsewhere, to me this (including Aarch64 in 8u) fits as an
> example of
> the “gut wrenching” necessary category, and IMO meets and passes the
> bar of
> "if we don't do this, the LTS will break and millions will be
> affected".
> 

The original email by Paul was about both Shenandoah and aarch64 (in 8u
no less). The reply was that 'Azul supports this idea'. In-fact, two
major vendors voicing their support for it was a primary motivator for
me to come up with this RFR in the first place.

Roman