New library dependencies due to 8222720 (fb5b3981eac)

[David Holmes]

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