[8u] RFR 8073108: Use x86 and SPARC CPU instructions for GHASH acceleration

[Andrew John Hughes]

On 21/11/2019 16:13, Martin Balao wrote:
> On 11/21/19 12:48 PM, Hohensee, Paul wrote:
>> You should be able to build a 32-bit linux jdk and test it on x32.
>>
> 
> Yes, I'll test on 32-bit.
> 
>> Does anyone on the list have access to a sparc box? I'm very hesitant to approve an untested backport. I'd be fine with just the x32/64 part though.
>>
> 
> I'm okay with removing the SPARC part if nobody is able to test there.
> 

While I see this has now been tested on SPARC, I think the general issue
is worth commenting on, as this is something I've often encountered with
OpenJDK 7 as well.

In the event that a particular OS or hardware can not be tested, I would
tend towards still including the changes. For OS or architecture support
to be fully supported, it needs active maintenance. It is perfectly
possible for things to break even without changes to specific code being
altered.  So what we're really looking at here is the potential outcome
when someone does try to build on that platform at some later date.
There are four potential outcomes, reducing to two depending on whether
the changes are included or not:

A.1. The changes are included and nothing is broken. No maintenance work
is required.

A.2. The changes are included, causing breakage because adaptations
needed to be made for the earlier OpenJDK version. The maintainer has to
make the necessary changes to fix the backport.

B.1. The changes are not included and nothing is broken. However, the
maintainer has to then find and complete such backports to bring the
platform in sync with others.

B.2. The changes are not included but breakage is caused by other
changes. The maintainer has to fix the breakage, and then work through
the backport backlog.

Looking at these alternatives from a potential maintainer perspective,
A.1 & A.2 are a preferable pair to B.1 & B.2. If we're lucky, nothing
needs to be done. If we're unlucky, the same work as would have been
needed at the time of the backport review needs to be done. Both are
preferable to not including the changes, where the maintainer has to
hunt down such changes and apply them, and may not have avoided breakage
by other means.

In short, platform support requires active maintenance and omitting such
changes just creates a greater burden for any future maintainer, with no
guarantee of avoiding breakage.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew