On Thu, Jul 23, 2020 at 8:48 PM Alan Bateman <alan.bate...@oracle.com> wrote: > > On 23/07/2020 18:18, Volker Simonis wrote: > > Hi, > >
Hi Alan, thanks for promptly looking into my proposal. Please find my answers inline: > > can I please get some reviews for the following small enhancement > > which will allow you to configure different zlib implementations at VM > > start-up and get up to 100% better throughput for compression and > > about 50% better throughput for decompression (depending on the > > selected zlib implementation). We're using a similar change > > productively in Amazon since quite a while with good results on > > compression/decompression heavy workloads. > > > > As usual, my write-up is moch longer and much more complex than the > > change itself :) > Yes, this needs discussion and agreement before starting an RFR. That's why we're here :) I'm happy to discuss all your concerns. But I don't think it does any harm to have a working implementation and detailed benchmark data as a basis for such a discussion :) > As you've summarized in the JIRA issue, we have configure > --with-zlib=system and --with-zlib=bundled today. The former is the way > to build when what to make it possible to use an alternative zlib. The > new requirement that I think you are brining up is the case where > someone wants to use several zlib libraries at the same time, because > they somehow know that one version has superior performance than the > other on some functions. That's true. And in addition it allows always choosing an alternative (e.g. the system) version even if the JDK was configured with a "bundled" zlib. That's not possible today and from my point of view already worth this change alone. > I think it's reasonable to ask if the JDK > really needs to support this complexity. 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 could imagine testing or > support folks in tears when they see the implications of this. Have you I don't see any implications for testing here. Please see my answer to Lance's mail for more details. > looked at alternatives that would benefit other users of zlib, e.g. an > interposer that dispatches to the appropriate zlib based on configuration? But that's exactly what I've implemented - a simple interposer which dispatches between various zlib implemations. It's pretty simple and convenient to use because of the fact that a lot of alternative, but fully API-cpmatible zlib implementations already exist today. I don't want to create and maintain a new, native library. I just want to enable users to leverage the existing ones. Best regards, Volker > > -Alan >
