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

[Andrew Dinn]

On 02/07/2020 20:36, Roman Kennke wrote:
> 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
And that brings me to a critique of Gil's 'in principle' argument. Gil
says we don't ever need to backport features, as opposed to critical
missing functionality (like the TLS code) or security/bug fixes (as
happens at every CPU). His reasoning is that there can be no risk from
sticking with the status quo to weigh against the risk that might be
introduced by pushing jdk11u into upstream i.e. his equation always
favours a conservative approach.

Well, I am afraid I see a risk here which does need to be balanced. It's
a well-known and widespread experience that maintaining a code base
offers a very real risk of injecting new defects when you try to fix old
ones. The academic literature and associated industrial experience of
defect injection derives from at least as early as the mid 80s (the work
I am aware of from that period was by IBM, I believe ;-).

So, what this means is that maintaining two jdk11u trees offers more
opportunities for bug injection when backporting critical missing
functionality or security/bug fixes than maintaining one consolidated
tree. We have two bites of the cherry where we might crack a tooth on
the pip.

We at Red Hat (well, our Shenandoah team in particular) know this
because we have been maintaining the two trees in question. Andrew Haley
and I also encountered the same concerns maintaining the AArch64 tree
before it was upstreamed -- and in that case we have direct experience
of the before and after situation which tells us that the risk on the
status quo side is very real. That experience means we can identify and
quantify risk on both sides of this Shenandoah equation and we certainly
know already that it is not a one way street.

Now, I am not saying anything about which way the balance lies in this
specific case. I am happy to trust the those who review the proposed
patch to follow the arguments of the Shenandoah team and their own
understanding of the code, assess the evidence and make a balanced
judgement (I am confident we have a sound review practice in this
project). What I do suggest is that the in principle argument is a red
herring and that we always need to look at and consider carefully what
risk is involved in the status quo vs the proposed new circumstance when
deciding on a backport.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill