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

David Holmes david.holmes at oracle.com
Tue Jul 30 20:55:53 UTC 2019


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