RFR (XS): 8078399: Deprecate -Xoss, -Xsqnopause, -Xoptimize and -Xboundthreads options in JDK 9

[Dmitry Dmitriev]

Hello David,

Please, see my comments inline.

On 23.06.2015 15:49, David Holmes wrote:
> Hi Dmitry,
>
> On 23/06/2015 8:35 PM, Dmitry Dmitriev wrote:
>> Hello,
>>
>> Please review this small fix which deprecate -Xoss, -Xsqnopause,
>> -Xoptimize and -Xboundthreads options in JDK 9. Also, I need a sponsor
>> for this fix, who can push it.
>
> I can sponsor this for you. But first ...
Thank you!
>
>> Currently HotSpot silently ignore these 4 options. Here are description
>> of these options:
>> "-Xoss", "-Xsqnopause", "-Xoptimize" - EVM option leaved for
>> compatibility. From Java 2 SDK for Solaris Developer's Guide: "Prior to
>> version 1.3.0, the production releases of the Java 2 SDK for the Solaris
>> Operating Environment shipped with a virtual-machine implementation
>> known as the Exact VM (EVM). Beginning with version 1.3.0, the Exact VM
>> is replaced by the Java HotSpot VM.". So, from Java 1.4 EVM is not used
>> as VM for JDK on Solaris and these very old flags just silently ignored
>> by HotSpot.
>> "-Xboundthreads" - was used to bind user level threads to kernel threads
>> on Solaris in case when new thread library is not available. But old T1
>> libthread has been removed from Solaris in release 10. JDK9 requires
>> Solaris 10u9 or higher. So, this flag become useless.
>>
>> All these options are deprecated, i.e. following warning is printed when
>> option is specified: "Java HotSpot(TM) 64-Bit Server VM warning: Option
>> -Xoss was deprecated in version 9.0 and will likely be removed in a
>> future release.". In next major release all these options can be 
>> removed.
>>
>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.00/
>> <http://cr.openjdk.java.net/%7Eddmitriev/8078399/webrev.00/>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078399
>> Tested: JPRT
>
> Can you not add these options to the set of obsolete_flags ? (and 
> delete the code that references them of course)
Unfortunately, I not understand what set of obsolete flags you mean. Do 
you mean os::obsolete_option method or obsolete_jvm_flags table? Since 
obsolete_jvm_flags is developed for "XX:" options I not see how it 
easily can be done. In case of os::obsolete_option methods then I will 
need to add these options to all implementations. Probably, I not 
understand you correctly.

Thanks,
Dmitry

>
> Thanks,
> David
>
>> Thanks,
>> Dmitry