FileDescriptor.sync isn't using Blocker

[Robert Engels]

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. 

> On Jul 13, 2023, at 8:09 AM, Brian S O'Neill <bronee at gmail.com> wrote:
> 
> I don't think changing the behavior is a priority, but I'm concerned about all the legacy libraries out there making use of `sync` which work just fine. They shouldn't have to be updated just because they appear to be causing issues when used with virtual threads. The temporary pinning due to a sync operation isn't that temporary when a lot of dirty pages need to be flushed out.
> 
>> On 2023-07-13 02:29 AM, Alan Bateman wrote:
>> You shouldn't need to worry about it, it will run just fine in a virtual thread, it just doesn't currently compensate so doesn't smooth over the temporary pinning. A static analysis of 485k libraries didn't find a lot of usage, at least not compared to all the other blocking I/O, probably not too surprising as the FileDescriptor can only be obtained from a small number of APIs (those that date from early JDK releases). We can include it in the next update but eventually it will be replaced as we want operations like this to release the carrier to do other work.
>> -Alan