New library dependencies due to 8222720 (fb5b3981eac)

[Lindenmaier, Goetz]

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);

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
> >>>