FileDescriptor.sync isn't using Blocker

[Brian S O'Neill]

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.