New library dependencies due to 8222720 (fb5b3981eac)

Rainer Jung rainer.jung at kippdata.de
Tue Jul 30 07:53:36 UTC 2019


Am 30.07.2019 um 09:50 schrieb David Holmes:
> Hi Rainer,
> 
> I have filed:
> 
> https://bugs.openjdk.java.net/browse/JDK-8228764

Thanks you.

> Matthias: I think we may have to backout JDK-8222720 from JDK 13, 
> re-examine this and re-do for 14.

It looks like it is also already in JDK 11 head for the forthcoming 11.0.5:

https://bugs.openjdk.java.net/browse/JDK-8226873

Regards,

Rainer

> 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