RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11]

[Andrew Haley]

On Mon, 15 Jul 2024 21:17:03 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> I think the key question is whether we're comfortable relying on/pointing at an external repository which may or may not be there tomorrow and/or where tags may change outside of our control.

Right. We should adopt best practice, both from an Open Source compliance point of view and (from a security, traceability, and binary reproduceability point of view) with regard to the xz backdoor hack.

> The SLEEF source code looks to be around 7.5MB, give or take. That's not enormous, but it's not exactly small when keeping in mind that if we `#include` it in the jdk repo it's going to be there for every cloned repo in every project/branch and very few will actually care about it. I agree that we'd still have to include the pre-generated header files.
> 
> Hence my suggestion to consider putting it under our control, but in a separate `openjdk` controlled repository.

That ticks many of the boxes, as long as we can be sure to tag everything. But from a space point of view I'm not sure it's compelling. After all, we've recently decided to use branches rather than separate repos for releases, which is a good idea because it keeps everything together, but it does increase the repo size for everyone.

It would be very nice if Git allowed a subset of the repo to be checked out, but as far as I can see it doesn't.

Before checkout, the OpenJDK repo is 1.4G. After checkout that's 2.1G. So, about 0.7G of that is the JDK source code, if you include the file system overhead.

7.5Mb doesn't sound excessive when you consider that SLEEF potentially provides vectorized routines for many OpenJDK targets. It's not just about AArch64.

This is starting to sound like we need a policy decision, because we don't want to re-hash this discussion every time the question comes up, as it surely will.  For me, that supplying preprocessed source code without real source is known bad practice, even to the extent of being expressly forbidden in the open source definition, is a slam-dunk argument. But clearly that argument doesn't work for everyone.  Maybe something to be discussed at the workshop?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230304980