RFR (S): 8181785: Remove the experimental ClearFPUAtPark JVM Flag

Daniel D. Daugherty daniel.daugherty at oracle.com
Fri Jun 9 16:29:11 UTC 2017


I agree. Primary reason is that it is experimental. Secondary reasons
are "unsafe" and "unstable".

Dan


On 6/9/17 10:23 AM, Erik Osterlund wrote:
> Hi Thomas, Dan and Robbin,
>
> Thank you for reviewing. As Dan pointed out - this JVM flag has always been advertised as unsafe and unstable, hence nobody should be using it.
>
> Do we agree we are okay with removing it without a CCC/CSR request?
>
> Thanks,
> /Erik
>
>> On 9 Jun 2017, at 17:06, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>
>> We have removed several experimental options without a CCC/CSR request.
>> This one is identified as:
>>
>> experimental(intx, ClearFPUAtPark, 0, "(Unsafe, Unstable)")
>>
>> Since it is flagged as "Unsafe" and "Unstable" (like one or two I removed
>> in JDK9), no one should be using it. It will not be noticed or missed.
>>
>> Dan
>>
>>
>>
>>> On 6/9/17 6:36 AM, Robbin Ehn wrote:
>>>> On 06/09/2017 02:27 PM, Thomas Schatzl wrote:
>>>> Hi Erik,
>>>>
>>>>> On Thu, 2017-06-08 at 17:04 +0200, Erik Österlund wrote:
>>>>> Hi,
>>>>>
>>>>> There is an experimental JVM flag called ClearFPUAtPark that is used
>>>>> only by SPARC. It is turned off by default and is marked as Unsafe
>>>>> and
>>>>> Unstable.
>>>>> The idea is to tell the Solaris kernel not to save floating point
>>>>> registers when context switching.
>>>>> I propose to remove it as it is an unstable option. It relies on an
>>>>> implicit unstable OS contract with the kernel that may or may not be
>>>>> honored.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181785
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~eosterlund/8181785/webrev.00/
>>>>>
>>>>> Testing: JPRT
>>>>>
>>>>> Will need a sponsor.
>>>>    looks good apart from copyright dates.
>>>>
>>>> As even experimental VM options are part of the public VM interface, I
>>>> think you need to do a CSR request.
>>>>
>>>> Further I think we can't just remove these options but need to use the
>>>> usual option deprecation/removal process.
>>> Hi, here the runtime process:
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-June/015277.html
>>>
>>>     release 1: Deprecate & Handle - warn and keep supporting
>>>     release 2: Deprecate & Obsolete - warn and do nothing
>>>     release 3: Dead - unrecognized
>>>
>>> But in this case I suggest going for 2 directly and let CSR guys object if so..
>>>
>>> /Robbin
>>>
>>>> Thanks,
>>>>    Thomas
>>>>



More information about the hotspot-runtime-dev mailing list