8228764: New library dependencies due to JDK-8222720 - was: New library dependencies due to 8222720 (fb5b3981eac)

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Tue Jul 30 14:26:05 UTC 2019


Hi Matthias, 

Thanks for picking up my proposal!
This looks good to me.

Best regards,
  Goetz.

> -----Original Message-----
> From: Baesken, Matthias
> Sent: Dienstag, 30. Juli 2019 16:21
> To: David Holmes <david.holmes at oracle.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Rainer Jung <rainer.jung at kippdata.de>;
> hotspot-runtime-dev at openjdk.java.net
> Cc: Doerr, Martin <martin.doerr at sap.com>
> Subject: RFR: 8228764: New library dependencies due to JDK-8222720 - was:
> New library dependencies due to 8222720 (fb5b3981eac)
> 
> 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