FileDescriptor.sync isn't using Blocker

[Cay Horstmann]

I found it hard to tell from the JEP what happens in such a case.

"However, some blocking operations in the JDK do not unmount the virtual thread, and thus block both its carrier and the underlying OS thread. This is because of limitations at either the OS level (e.g., many filesystem operations) or the JDK level (e.g., Object.wait()). The implementations of these blocking operations compensate for the capture of the OS thread by temporarily expanding the parallelism of the scheduler."

But later:

"The scheduler does not compensate for pinning by expanding its parallelism."

Am I missing some subtlety here?

Thanks,

Cay


Il 13/07/2023 18.19, Robert Engels ha scritto:
> But isn’t this automatically done for native calls via jni which is where fd.sync() ends up? If it it didn’t that would mean that the carrier thread pool could be exhausted by a small number of threads that blocked in a jni call - like a wait for an OS signal.
> 
> Although in the case of fd.sync the time blocked is bounded.
> 
> I’ll have to research the VT/jni handling more next week.
> 
> Thanks for sharing.
> 
>> On Jul 13, 2023, at 9:30 AM, Brian S O'Neill <bronee at gmail.com> wrote:
>>
>> package jdk.internal.misc;
>> ...
>>
>> /**
>> * Defines static methods to mark the beginning and end of a possibly blocking
>> * operation. The methods are intended to be used with try-finally as follows:
>> * {@snippet lang=java :
>> *     long comp = Blocker.begin();
>> *     try {
>> *         // blocking operation
>> *     } finally {
>> *         Blocker.end(comp);
>> *     }
>> * }
>> * If invoked from a virtual thread and the underlying carrier thread is a
>> * CarrierThread then the code in the block runs as if it were in run in
>> * ForkJoinPool.ManagedBlocker. This means the pool can be expanded to support
>> * additional parallelism during the blocking operation.
>> */
>> public class Blocker ...
>>
>>
>>> On 2023-07-13 08:21 AM, Robert Engels wrote:
>>> My apologies though if the above is not correct as I can’t review your reference to Blocker and the JEP makes no mention. I don’t have east access to the source at the moment.
>>>>> On Jul 13, 2023, at 9:18 AM, Robert Engels <rengels at ix.netcom.com> wrote:
>>>>
>>>> 
>>>> I don’t think that is correct. From the JEP “ The implementations of these blocking operations compensate for the capture of the OS thread by temporarily expanding the parallelism of the scheduler. ”
>>>>
>>>> The number of OS threads will be expanded to compensate for the blocking call. I believe the call to fd.sync() ends up being no different than an arbitrary native call. The same actions occur.
>>>>
>>>>> On Jul 13, 2023, at 8:28 AM, Brian S O'Neill <bronee at gmail.com> wrote:
>>>>>
>>>>> An application which relies on a non-virtual thread pool can spin up more platform threads to compensate, and so a sync isn't necessarily an issue. Virtual threads limit the amount of carrier threads they depend on, and so a virtual thread stuck on a sync can prevent other virtual threads from making progress. The internal Blocker class is intended to help compensate for this behavior.
>>>>>
>>>>> On 2023-07-13 07:13 AM, Robert Engels wrote:
>>>>>> It is no worse than the current behavior. If it was a platform thread it would block. The virtual threads carrier thread blocks and a new carrier is spawned. So this would only be a performance optimization not a regression against current performance.

-- 

--

Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com