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. > > 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. That situation leads to my nightmare, in which some OpenJDK builds work with vector support, and some don't, and there's no way to find out which unless you try it, in which case there is no warning, your programs just run slowly. Even if you've installed SLEEF. That would be bad for our users, bad for OpenJDK, and bad for Java. > But it's not harm to do so. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2014634593
