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

[Ioi Lam]

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