On Fri, Jul 24, 2020 at 2:15 PM Alan Bateman <alan.bate...@oracle.com> wrote: > > > On 24/07/2020 12:48, Volker Simonis wrote: > > : > > > > I can't see much complexity here. If you look at the change you'll see > > that it's rather trivial. All it does is substituting some direct > > calls into the zlib library by indirect calls through > > function pointers. > > > I don't think the JDK should be in the business of loading several > versions of zlib at the same time and using some functions from one > version, and some functions from another. Have you explored solutions > that don't burden the JDK? Has there been any attempt to bring the > performance improvements from the different sources into one build as > that seems to be what you are really looking for. >
I really don't want to maintain yet another native zlib clone or a merge of existing ones. There are plenty of them available with their own strengths and weaknesses. I only want to make it easy and convenient for everybody to consume them from the JDK. The whole proposal is really just a simpler, more standard (because system independant) and more powerful way of using LD_LIBRAY_PATH. Additionally, it gives you the choice to use an alternative implementation even on platforms like Windows where we currently can't link dynamically because a default system version doesn't exist. Until now I'm only hearing mostly high-level ,theoretical arguments against the proposal rather than technical objections. Why are you so strictly against providing this additional choice to users which comes at almost zero costs for the JDK? > I would expect most/all of the Linux distributions to configure > --with-zlib=system as they don't want a zlib in the JDK run-time image. > So it might be unusual to build with --with-zlib=bundled and then expect > to be able to use an alternative zlib. There was a good discussion on > this topic on build-dev in 2016 as there was interest from Intel > engineers at the time to be able to use their accelerated library. > Yes, I know that discussion [1] and the previous one from Sandhya in 2015 [2] as well. The latter was a similar, but much more limited idea compared to my solution. It prosed an option/property to switch between the bundled and the system version at startup. The former was merely about changing the build default from "bundled" to "system" on Linux/Solaris. During that discussion, concerns were raised and finally disregarded that dynamic linking might introduce unpredictable risks compared to the bundled solution. I think my proposal is really combining and extending all the requests and concerns of the previous discussions in an ideal way by offering maximum flexibility paired with the ability of a safe fall-back at virtually no costs. [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/thread.html#38649 [2] https://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/thread.html#32106 > Separately, I think it would be useful to explore some of the examples > to see if they make use of the Vector API or if there are opportunities > to do pure Java implementations that would benefit from the runtime > compilers. > I've briefly looked into the alternative implementations and they all make use of vector instructions, assembler coding and optimizations like manual loop unrolling etc. Most of these optimizations are currently hard to realize in a bundled, native version because we don't have a framework in the class library for dynamically checking CPU features. Implementing Inflation/Deflation in pure Java would surely be an interesting project but from my point of view not very realistic in the foreseeable future (I remember you were already throwing in similar ideas in the 2016 discussion mentioned above :) Best regards, Volker > -Alan
