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

[Paul Sandoz]

I share your concerns about code maintainability. I have every confidence that Intel’s contributors to OpenJDK are prepared to maintain the code and provide fixes.

In this case I would argue that what is being proposed here is very unique: under incubation for highly specialized implementations of numerical operations from a well regarded library, while exploring alternative bindings during further incubation with enhancements to Panama.

I don’t think this should be considered a generally acceptable approach for Vector API operations (most code for operations does not and should not follow this approach), nor is it generally acceptable for other kinds of intrinsic in HotSpot (I believe there are a few special cases under os_cpu). Thus we should dissuade the use of .S source for other intrinsic cases.

Does this help alleviate some of your concerns?

Paul.
 
> On May 19, 2021, at 1:48 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 5/17/21 6:51 PM, Paul Sandoz wrote:
>> I’ll let Sandhya talk more about the provenance and numerical accuracy. I think we can add more comments/details in that respect.
>> 
>> IMO this is a reasonable compromise, at least for incubation with follow on investigation to determine if we can leverage possible enhancements to Panama FFM (see JEP 414 section on SVML). We would like encourage experimentation of numerical data-parallel algorithms. The performance gains using SVML are compelling in that regard.
> 
> I understand the argument from utility here, but it's a very substantial
> precedent to take. In the licence we use for OpenJDK, the "source code" for
> a work means the preferred form of the work for making modifications to it.
> This is not the preferred form. These assembly-code files are not much more
> use than binary blobs would be. They are a black box.
> 
> (I'm aware that we've had a few of these from Intel before, but ISTM that
> this is a much bigger deal.)
> 
> I understand that permission to include these files was probably granted as
> a result of negotiations with Intel. And it's great to have this code in
> OpenJDK.
> 
> However, I am sure that no-one on this project looks forward to a future
> in which part of our "source code" consists of what are in effect unfixable
> binary blobs. We should at least have the conversation about whether this
> is the way OpenJDK should be going.
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://urldefense.com/v3/__https://www.redhat.com__;!!GqivPVa7Brio!Muzl015fdf6qlmfWYY3Lr9llw8tGfFwoTzRPYg7wbpeoAOajiDTgxVdS5ls85HIOEg$ >
> https://urldefense.com/v3/__https://keybase.io/andrewhaley__;!!GqivPVa7Brio!Muzl015fdf6qlmfWYY3Lr9llw8tGfFwoTzRPYg7wbpeoAOajiDTgxVdS5luVfUunGg$ 
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>