New library dependencies due to 8222720 (fb5b3981eac)
matthias.baesken at sap.com
Tue Jul 30 08:18:32 UTC 2019
Hi David, in our proprietary JVM we have an XX flag to enable/disable the usage of the guestlib for people who don't want it .
Should I go for this ?
Best regards, Matthias
> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Dienstag, 30. Juli 2019 09:51
> To: Rainer Jung <rainer.jung at kippdata.de>; hotspot-runtime-
> dev at openjdk.java.net; Baesken, Matthias <matthias.baesken at sap.com>
> Subject: Re: New library dependencies due to 8222720 (fb5b3981eac)
> Hi Rainer,
> I have filed:
> Matthias: I think we may have to backout JDK-8222720 from JDK 13,
> re-examine this and re-do for 14.
> On 30/07/2019 5:34 pm, Rainer Jung wrote:
> > Hi David,
> > Am 30.07.2019 um 01:56 schrieb David Holmes:
> >> Hi Rainer,
> >> On 30/07/2019 7:34 am, Rainer Jung wrote:
> >>> While doing Tomcat tests I noticed, that at least on SLES 12 JDK 13
> >>> and 14 EA have a lot of new runtime library dependencies.
> >>> Change fb5b3981eac with log
> >>> 8222720: Provide extended VMWare/vSphere virtualization related info
> >>> in the hs_error file on linux/windows x86_64
> >>> loads /usr/lib64/libguestlib.so.0 already during JVM startup. That
> >>> library depends on /usr/lib64/libvmtools.so.0, which in turn depends
> >>> on a lot of other libraries:
> >>> NEEDED libdnet.so.1
> >>> NEEDED libglib-2.0.so.0
> >>> NEEDED libicui18n.so.52.1
> >>> NEEDED libicuuc.so.52.1
> >>> NEEDED libpthread.so.0
> >>> NEEDED libdl.so.2
> >>> NEEDED libssl.so.1.0.0
> >>> NEEDED libcrypto.so.1.0.0
> >>> NEEDED libc.so.6
> >>> NEEDED ld-linux-x86-64.so.2
> >>> NEEDED libgcc_s.so.1
> >>> Some are not so problematic, but for instance Tomcat is able to use
> >>> custom build OpenSSL libraries to replace the JSSE crypto engine with
> >>> an OpenSSL based one using JNI. Unfortunately the JDK is now loading
> >>> libssl and libcrypto early. In case our TC OpenSSL also uses SO
> >>> version 1.0.0 it will not get loaded, in case it is another version
> >>> we can run into a mix of symbols resolved in the platform OpenSSL
> >>> libs now loaded early and the ones provided with TC loaded later.
> >>> This is an example, why it would be good to not introduce too many
> >>> native library dependencies for the JVM or make it optional in the
> >>> sense of configurable during runtime. Of the above list, the icu
> >>> libs, libglib and libdnet are other libs one would probably try to
> >>> avoid.
> >>> Don't know whether this list is appropriate for discussing it. If not
> >>> any pointers to a better list are appreciated.
> >> This is the correct list to discuss this.
> >> When 8222720 was put in I had no idea it would result in eager loading
> >> of libraries beyond the explicit load of libguestlib.
> >> To be clear you are running under VMWare? This should only happen to
> >> enable reporting for the VMWare virtualization info in case of a crash.
> > Yes, I am running under VMWare. The library /usr/lib64/libguestlib.so.0
> > and its dependency /usr/lib64/libvmtools.so.0 both belong to the package
> > libvmtools0. Its sources seem to be available at
> > https://github.com/vmware/open-vm-tools.
> >> This may need to be revisited.
> >> Thanks for the report.
> > Thanks for looking at this!
> > Rainer
More information about the hotspot-runtime-dev