[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-hotspot-runtime-dev
Subject: Re: New library dependencies due to 8222720 (fb5b3981eac)
From: David Holmes <david.holmes () oracle ! com>
Date: 2019-07-30 11:51:09
Message-ID: 9d637309-c569-b35c-8cd9-62d48f521e7b () oracle ! com
[Download RAW message or body]
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@openjdk.java.net>
>> On Behalf Of David Holmes
>> Sent: Dienstag, 30. Juli 2019 10:39
>> To: Baesken, Matthias <matthias.baesken@sap.com>; Rainer Jung
>> <rainer.jung@kippdata.de>; hotspot-runtime-dev@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@oracle.com>
>>>> Sent: Dienstag, 30. Juli 2019 09:51
>>>> To: Rainer Jung <rainer.jung@kippdata.de>; hotspot-runtime-
>>>> dev@openjdk.java.net; Baesken, Matthias <matthias.baesken@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
>>>>>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic