Obsoleting JavaCritical

[coleen.phillimore at oracle.com]

On 6/28/22 12:04 PM, Erik Osterlund wrote:
> Hi,
>
> Generational ZGC currently depends on CriticalJNINatives not existing, which was a valid move when it was removed. We didn’t anticipate it would suddenly come back from the dead. Ouch.

When we deprecated CriticalJNINatives, there were changes to remove the 
special GC code that blocked GC while this function is in native.  So it 
won't break Generational ZGC.
Thanks,
Coleen


>
> /Erik
>
>> On 28 Jun 2022, at 15:46, coleen.phillimore at oracle.com wrote:
>>
>> 
>> Hi,
>>
>> I've filed https://bugs.openjdk.org/browse/JDK-8289302 to restore CriticalJNINatives until replacement intrinsics are found.
>>
>> Thanks,
>> Coleen
>>
>>> On 6/7/22 1:31 PM, mark.reinhold at oracle.com wrote:
>>> 2022/6/6 0:24:17 -0700, wkudla.kernel at gmail.com:
>>>>> Yes for System.nanoTime(), but System.currentTimeMillis() reports
>>>>> CLOCK_REALTIME.
>>>> Unfortunately System.currentTimeMillis() offers only millisecond
>>>> granularity which is the reason why our industry has to resort to
>>>> clock_gettime.
>>> If the platform included, say, an intrinsified System.nanoRealTime()
>>> method that returned clock_gettime(CLOCK_REALTIME), how much would
>>> that help developers in your unnamed industry?
>>>
>>> In a similar vein, if people are finding it necessary to “replace parts
>>> of NIO with hand-crafted native code” then it would be interesting to
>>> understand what their requirements are.  Some simple enhancements to
>>> the NIO API would be much less costly to design and implement than a
>>> generalized user-level native-call intrinsification mechanism.
>>>
>>> - Mark