RFR: 8228764: New library dependencies due to JDK-8222720 - was: New library dependencies due to 8222720 (fb5b3981eac)
Baesken, Matthias
matthias.baesken at sap.com
Wed Jul 31 07:11:21 UTC 2019
Hi David, thanks for the review !
I requested The approval in JBS.
Best regards, Matthias
>
> Hi Matthias,
>
> On 31/07/2019 12:21 am, Baesken, Matthias wrote:
> > Hello , I prepared a webrev following the idea proposed by Goetz ; please
> review !
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8228764.0/
>
> Looks good. Thanks for fixing.
>
> Please proceed with the RDP2 approval process to get this into 13 (it
> will then automatically propagate to 14).
>
> Thanks,
> David
> -----
>
> > 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