RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics

[Viswanathan, Sandhya]

Hi Andrew/John,

We made this contribution with the goal to help Vector API and its evaluation during incubation. This is the best we could do currently towards JDK 17.
Please advice if you think that PR be withdrawn instead of integration at this point.  We will go with your expert advice.

Best Regards,
Sandhya


-----Original Message-----
From: hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> On Behalf Of Andrew Haley
Sent: Friday, May 21, 2021 12:40 AM
To: John Rose <john.r.rose at oracle.com>
Cc: Paul Sandoz <paul.sandoz at oracle.com>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
Subject: Re: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics

On 5/20/21 7:54 PM, John Rose wrote:
> On May 20, 2021, at 8:31 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 5/20/21 12:34 AM, Paul Sandoz wrote:
>>
>>> Does this help alleviate some of your concerns?
>>
>> Somewhat, but I wonder if this, as a matter of policy, is an area in 
>> which the Governing Board should get involved. I don't want to hold 
>> up progress, of course, but this is potentially a very important issue.
>
> I think this could rise to the GB level if we needed to make a strong 
> policy change, but as I’ve said above, I think we are in policy here.
> (Just barely.)  For any conceivable issue of maintainability, surely 
> the open review process is enough, without asking the GB to weigh in 
> on change set reviews.  And I think this is about maintainability.

It is, but that's not not entirely what I'm worried about. The four
(software) freedoms are:

    The freedom to run the program as you wish, for any purpose
    (freedom 0).

    The freedom to study how the program works, and change it so
    it does your computing as you wish (freedom 1). Access to the
    source code is a precondition for this.

    The freedom to redistribute copies so you can help your neighbor
    (freedom 2).

    The freedom to distribute copies of your modified versions to
    others (freedom 3). By doing this you can give the whole
    community a chance to benefit from your changes. Access to the
    source code is a precondition for this. but not entirely.

In this case we have 0, 2, and 3, but not 1. So, this issue is about more than mere utility, but something more fundamental. It's about the right of our users to understand how OpenJDK works.

My question is, then, (please forgive the paraphrase), are we giving up essential freedom to purchase a little temporary utility?

> Intel is contributing them as a one-time artifact which we are, in 
> fact, responsible to maintain.  By hand, as the preferred form of the 
> source.  (Preferred to what??  Well, preferred to nothing at all.)

NB: "preferred form" is a term used (but not fully defined) in GPLv2. It's not easy to define, but we know it when we see it: it's the form a programmer prefers to edit, the original source code.

> Well in this case, we have two things:
>
> 1. Temporary expedient only for incubation, to gain public feedback.
> 2. Clear call for a plausible alternative, to be answered before incubation exit.

OK, but I don't hold out much hope of 2 actually succeeding before incubation exit.

> That’s probably enough “case law” to help clarify the relevant policy.
>
> What do you think?

I think that's OK, as long as it's well-enough understood.

By the way, slightly off topic: being rather conflict averse I did wonder whether I should object to this commit, but I reasoned that this kind of issue is exactly the reason that we have a governing board with community representatives. It's literally my duty.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671