RFR: 8228764: New library dependencies due to JDK-8222720 - was: New library dependencies due to 8222720 (fb5b3981eac)
Baesken, Matthias
matthias.baesken at sap.com
Tue Jul 30 14:21:09 UTC 2019
Hello , I prepared a webrev following the idea proposed by Goetz ; please review !
http://cr.openjdk.java.net/~mbaesken/webrevs/8228764.0/
bug opened by David :
https://bugs.openjdk.java.net/browse/JDK-8228764
Best regards, Matthias
> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Dienstag, 30. Juli 2019 13:51
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; Rainer Jung <rainer.jung at kippdata.de>;
> hotspot-runtime-dev at openjdk.java.net
> Subject: Re: New library dependencies due to 8222720 (fb5b3981eac)
>
> Hi Goetz,
>
> On 30/07/2019 9:06 pm, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > there is already -XX:ExtensiveErrorReports with default 'false'.
> > It's supposed to guard additional infos in the hs_err file.
> > As it's already available, no CSR should be needed.
> >
> > Can't we just use this? Below tiny fix should do the job.
> >
> > diff -r 144585063bc8 src/hotspot/share/utilities/virtualizationSupport.cpp
> > --- a/src/hotspot/share/utilities/virtualizationSupport.cpp Tue Jul 30
> 11:14:16 2019 +0800
> > +++ b/src/hotspot/share/utilities/virtualizationSupport.cpp Tue Jul 30
> 13:04:58 2019 +0200
> > @@ -40,6 +40,9 @@
> > static char extended_resource_info_at_startup[600];
> >
> > void VirtualizationSupport::initialize() {
> > +
> > + if (!ExtensiveErrorReports) return;
> > +
> > // open vmguestlib and bind SDK functions
> > char ebuf[1024];
> > dlHandle = os::dll_load("vmGuestLib", ebuf, sizeof ebuf);
>
> That seems quite reasonable to me - this is extended error information.
>
> Great suggestion!
>
> Thanks,
> David
>
> > Best regards,
> > Goetz.
> >
> >> -----Original Message-----
> >> From: hotspot-runtime-dev <hotspot-runtime-dev-
> bounces at openjdk.java.net>
> >> On Behalf Of David Holmes
> >> Sent: Dienstag, 30. Juli 2019 10:39
> >> To: Baesken, Matthias <matthias.baesken at sap.com>; Rainer Jung
> >> <rainer.jung at kippdata.de>; hotspot-runtime-dev at openjdk.java.net
> >> Subject: Re: New library dependencies due to 8222720 (fb5b3981eac)
> >>
> >> Hi Matthias,
> >>
> >> On 30/07/2019 6:18 pm, Baesken, Matthias wrote:
> >>> 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 ?
> >>
> >> We can look at that for 14 but for 13 (and 11.0.5) I think we just need
> >> to back this out.
> >>
> >> Thanks,
> >> David
> >>
> >>>
> >>> 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:
> >>>>
> >>>> https://bugs.openjdk.java.net/browse/JDK-8228764
> >>>>
> >>>> Matthias: I think we may have to backout JDK-8222720 from JDK 13,
> >>>> re-examine this and re-do for 14.
> >>>>
> >>>> Thanks,
> >>>> David
> >>>> -----
> >>>>
> >>>> 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
mailing list