RFR(XXS): 8188109 JVM should print a warning message that -Xshare:on may cause VM to abort start-up

[Ioi Lam]

Another option is to change the behavior of -Xshare:on to be the same as 
-Xshare:auto. CDS is supposed to be a caching optimization. The VM 
should not fail just because an optimization doesn't pan out.

I can file a CSR for this.

What do you think?

Thanks
- Ioi

On 5/30/18 9:01 PM, Ioi Lam wrote:
>
>
> On 5/30/18 6:47 PM, David Holmes wrote:
>> Hi Ioi,
>>
>> Sorry but this troubles me ...
>>
>> On 31/05/2018 9:39 AM, Ioi Lam wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8188109
>>> http://cr.openjdk.java.net/~iklam/jdk11/8188109-xshare-on-print-warning.v01/ 
>>>
>>>
>>>
>>> Hi,
>>>
>>> Please review this one-liner patch.
>>>
>>> -Xshare:on may cause infrequent/intermittent start-up failure due to 
>>> the presence of Address Space Layout Randomization (ASLR). This 
>>> option is intended for testing (the internals of CDS) only and 
>>> should not be used in production environments.
>>>
>>> With this patch, the following warning message is printed when 
>>> -Xshare:on is specified:
>>>
>>> $ java -Xshare:on -version
>>> Java HotSpot(TM) 64-Bit Server VM warning: -Xshare:on is for testing 
>>> purpose only and may cause JVM start-up failure. Use -Xshare:auto 
>>> instead.
>>> java version "11-internal" 2018-09-25
>>> Java(TM) SE Runtime Environment 18.9 (fastdebug build 
>>> 11-internal+0-adhoc.iklam.open)
>>> Java HotSpot(TM) 64-Bit Server VM 18.9 (fastdebug build 
>>> 11-internal+0-adhoc.iklam.open, mixed mode, sharing)
>>
>> So should this warning only be enabled in product builds?
>>
>> Even then it may be annoying for anyone who runs with -Xshare:on as 
>> they've set up CDS as documented [1][2] and they know their 
>> environment works ok - now they get a warning.
>>
>> Also I'm unclear how "on" fails due to ASLR but "auto" keeps going?
>>
> The documentation [1] says:
>
> -Xshare:on
> To enable class data sharing. If class data sharing can't be enabled, 
> print an error message and exit.
>
> -Xshare:auto
> To enable class data sharing by default. Enable class data sharing 
> whenever possible.
>
> So if mapping fails due to ASLR, "on" will exit and "auto" will 
> disable CDS and continue .
>
> The documentation in [2] is wrong.  It says "Ensure that you have 
> specified the option -Xshare:on or -Xshare:auto.", but -Xshare:on 
> should not be used in production environments. I have filed a doc bug 
> for this (https://bugs.openjdk.java.net/browse/JDK-8204141).
>
> The main reason for doing this REF is -- if people have been following 
> [2] and using -Xshare:on, their setup is NOT OK. ASLR may happen just 
> very rarely, but you don't want your program suddenly failing (e.g., 
> if some admin has turned on more aggressive ASLR settings).
>
> As more people are moving their Java workload to micro-services type 
> of environments, JVM launches will happen more, and there will be more 
> chances of running into the ASLR issue. Therefore, we should fix the 
> docs, and warn people that they should switch to -Xshare:auto.
>
>> Maybe only if the archive mapping fails and "on" was used then give a 
>> warning? Or just improve the message given when the VM aborts?
>>
> That's already too late, especially for people running critical services.
>
> We want people to see this warning and actively fix their scripts to 
> get rid -Xshare:on.
>
> Thanks
> - Ioi
>
>
>>
>> Thanks,
>> David
>>
>> [1] 
>> https://docs.oracle.com/javase/10/vm/class-data-sharing.htm#JSJVM-GUID-0260F857-A70E-4399-A1DF-A5766BE33285
>> [2] 
>> https://docs.oracle.com/javase/10/tools/java.htm#JSWOR-GUID-31503FCE-93D0-4175-9B4F-F6A738B2F4C4
>>
>>>     --- vs ---
>>>
>>> $ java-Xshare:auto -version
>>> java version "11-internal" 2018-09-25
>>> Java(TM) SE Runtime Environment 18.9 (fastdebug build 
>>> 11-internal+0-adhoc.iklam.open)
>>> Java HotSpot(TM) 64-Bit Server VM 18.9 (fastdebug build 
>>> 11-internal+0-adhoc.iklam.open, mixed mode, sharing)
>>>
>>> I am testing with HotSpot tiers 1-3 to make sure the tests don't get 
>>> tripped by this new warning message.
>>>
>>> Thanks
>>> - Ioi
>