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

Dmitry Dmitriev dmitry.dmitriev at oracle.com
Wed Jun 24 10:36:13 UTC 2015


Hello David,

I update code and now print similar message and use JVM_Version. Thank you!

Webrev.01: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.01/ 
<http://cr.openjdk.java.net/%7Eddmitriev/8078399/webrev.01/>

Now warning message looks like this:
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option -Xoss; 
support was removed in 9.0

This message have small difference with  "-XX" options: "-XX" option 
strip "-XX:", but I print full optionString. But I can remove "-X" and 
just print option name(e.g. "oss") by passing "option->optionString + 2" 
to the warning function. What you think about that?

Thank you,
Dmitry


On 24.06.2015 7:25, David Holmes wrote:
> Hi Dmitry,
>
> On 23/06/2015 11:02 PM, Dmitry Dmitriev wrote:
>> 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.
>
> It was the obsolete_jvm_flags table I meant - sorry about the typo. 
> Pity it doesn't support -X options. :(
>
> My only suggestion here is to at least use the same warning message as 
> would be seen for obsolete -XX flags (something I should have 
> suggested when reviewing the CCC request):
>
> warning("ignoring option %s; support was removed in %s", 
> stripped_argname, version);
>
> ref:
>
>  > java -XX:+UseOldInlining -version
> Java HotSpot(TM) Server VM warning: ignoring option UseOldInlining; 
> support was removed in 9.0
>
> vs
>
> > java -Xoss -version
> Java HotSpot(TM) Server VM warning: Option -Xoss was deprecated in 
> version 9.0 and will likely be removed in a future release.
>
>
> and if you use an actual JVM_Version then this won't need to be 
> updated when the new version string comes in. :)
>
> Thanks,
> David
>
>> Thanks,
>> Dmitry
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> Thanks,
>>>> Dmitry
>>



More information about the hotspot-dev mailing list