RFR: 8293067: (fs) Implement WatchService using system library (macOS) [v10]

[Maxim Kartashev]

On Wed, 30 Nov 2022 03:20:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I just noticed a curious line in the documentation for `FSEventStreamStart()`:
>>>  It ought to always succeed, but in the event it does not then your code should fall back to performing recursive scans of the directories of interest as appropriate.
>> 
>> So I added a check for the return value of `FSEventStreamStart()`; if anyone who has seen tests failing (@AlanBateman @jaikiran) could please re-run some of them to see if an `InternalError` gets thrown, we can at least establish that the fallback mechanism the documentation talks about actually has to be implemented, which will give us a way to move forward.
>> 
>> Thanks in advance!
>
>> I just noticed a curious line in the documentation for `FSEventStreamStart()`:
>> 
>> > It ought to always succeed, but in the event it does not then your code should fall back to performing recursive scans of the directories of interest as appropriate.
>> 
>> So I added a check for the return value of `FSEventStreamStart()`; if anyone who has seen tests failing (@AlanBateman @jaikiran) could please re-run some of them to see if an `InternalError` gets thrown, we can at least establish that the fallback mechanism the documentation talks about actually has to be implemented, which will give us a way to move forward.
>> 
>> Thanks in advance!
> 
> I gave this latest state of the PR a try and the tests continue to fail across various versions of the macos, like previously. I even noticed a JVM crash:
> 
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007fff206a1b2e, pid=xxxx, tid=xxxx
> #
> # JRE version: Java(TM) SE Runtime Environment (20.0) (build 20-internal-2022-11-29)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20-internal-2022-11-29, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
> # Problematic frame:
> C [CoreFoundation+0x14ab2e]  _CFGetNonObjCTypeID+0xa
> 
> (it could be that the JVM crash was present even in previous version of this PR before your latest commit - I hadn't looked into all log files).

@jaikiran The tests were supposed to continue to fail, but this time there was a chance to diagnose the failure by checking if an InternalError was thrown from my latest commit. Have you seen any in the test logs?

-------------

PR: https://git.openjdk.org/jdk/pull/10140