On Thu, 21 Mar 2024 15:43:28 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>>> > The problem I see is that J. Random Java User has no way to know if SLEEF >>> > is making their program faster without running benchmarks. They'll put >>> > SLEEF somewhere and hope that Java uses it. >>> >>> Please kindly correct me if I misunderstood your points. Seems the safest >>> solution to address your above concerns is to integrate the sleef source >>> into jdk? Lack of sleef at either build time or runtime will make the >>> user's code fall back to java implementation. >> >> Exactly, yes. That's why we've integrated the source code of many other >> libraries we depend on into the JDK. It's the only way to get the >> reliability our users expect. > > @theRealAph Are you saying that bundling the source code of libsleef is a > hard requirement from your side to accept this code into the JDK? > > I'm not against it, I just want to understand what we're talking about here. > > In general, adding new libraries to OpenJDK will require a legal process in > Oracle, which may (or may not) take some amount of time T, where T is larger > than you'd wish for. > > So I guess we can either: > 1) wait for libsleef source code to become a part of OpenJDK, and then > integrate this PR. > 2) integrate this PR optimistically, and in the background start a process of > trying to get libsleef into OpenJDK. (Which, of course, can not be 100% > guaranteed to happen.) > 3) integrate this PR as is, and give up any idea of bundling libsleef. > > I also believe there is a fourth option, but that too seems like it has legal > implications that needs to be checked: > > 4) if the libsleef dynamic library is found on the system during build time, > bundle a copy of the dll with the built JDK. (Similar to how was done with > freetype on Windows before.). And, optionally, provide an option for > configure to require libsleef to be present, so the build fails if no > libsleef can be found and bundled. (Leaving open as to if this should be > default or not.) @magicus @theRealAph Thanks for discussion. > I think that's probably best the best thing to do today. I will approve it. Great, Thanks. > I'd prefer, long term, to integrate SLEEF into OpenJDK. That would make > AArch64 support similar to Intel. We are competing with Intel. I'm working on it, running some tests. But I think as @magicus pointed out, to achieve this target one of most important tasks is to get the legal process done. > In the short term, I'd build a shim library during the default standard JDK > build that does not need SLEEF at build time. Unless weo do that, because > SLEEF isn't on anyone's builders, it won't be used. I agree it's give user more chance to leverage the sleef when running, but I wonder if it's necessary to do that. As we have a long term solution, and the chance that end user lacks sleef library in their environment is much higher than release engineer lacks sleef library in their environment. But it's not harm to do so. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2013123992
