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

[Alan Bateman]

On Fri, 30 Sep 2022 05:17:43 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> This is an implementation of `WatchService` based on File System Events API that is capable of generating events whenever a change occurs in an interesting directory or underneath it. Since the API naturally supports "recursive" watch, the `FILE_TREE` is supported by the watch service. 
>> 
>> Some things of note:
>> * There's one "service" thread per `WatchService` instance that is inactive unless changes occur in the watched directory. The changes are grouped by introducing a time delay between when they occurred and when they are reported, which is controlled by the sensitivity modifier of the watch service.
>> * Since FSEvents API reports directories only, the watch service keeps a snapshot (hierarchical if necessary) of the files in the directory being watched. The snapshot gets updated when an event in that directory or underneath it gets delivered. File changes are detected by comparing "last modified" time with a millisecond precision (`BasicFileAttributes.lastModifiedTime()`).
>> * There is a slight complication with the move of an entire directory hierarchy: FSEvents API only reports about the containing directory of that move and not about any of the directories actually moved. There's a separate test for that (`Move.java`).
>> * The code is careful not to do any I/O (such as reading the contents of a directory or attributes of a file) unless unavoidable. Any deviation from this line should be considered a bug (of, arguably, low priority).
>> * The native part consists mostly of API wrappers with one exception of the callback function invoked by the system to report the events that occurred. The sole task of the function is to convert from C strings to Java strings and pass the array of affected directories to Java code. This can be rewritten if desired to make the code more future-proof.
>> 
>> This commit leaves `PollingWatchService` unused. I'm not sure if I should/can do anything about it. Any advice is welcomed.
>> 
>> ### Testing
>> 
>> * Tested by running `test/jdk/java/nio/file` and `test/jdk/jdk/nio` on MacOS 10.15.7 (x64) and `test/jdk/java/nio/` plus `test/jdk/jdk/nio` on MacOS 12.5.1 (aarch64).
>> * Also verified that new tests pass on Linux and Windows.
>> * This code (albeit in a slightly modified form) has been in use at JetBrains for around half a year and a few bugs have been found and fixed during that time period.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dropped __unused attributes from used parameters

It's a real shame that it requires use of a CFRunLoop and callbacks but if that is the only facility that it provides then I suppose we have to use it. I see the discussion about using a socketpair but I don't think that is sensible thing to do here. The socketpair that is used elsewhere is for wakeup only, similar to what we do in the Selector implementations. So I think we should move forward with the current approach but probably will need a few rounds of cleanup.

src/java.base/share/native/libnio/nio_util.c line 37:

> 35: {
> 36:     JNIEnv *env;
> 37:     jvm = vm;

Would it be possible for MacOSXWatchService to use GetJavaVM is its initializer so that the changes to nio_util.* can be reverted?

test/jdk/jdk/nio/zipfs/test.policy line 7:

> 5:     permission java.util.PropertyPermission "user.dir","read";
> 6:     permission java.lang.RuntimePermission "accessUserInformation";
> 7:     permission java.lang.RuntimePermission "loadLibrary.nio";

Why it this needed? It suggests there is a problem elsewhere so would be good to see the exception.

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

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