[crac] RFR: Linux file system watcher support

[joeylee]

On Mon, 15 May 2023 13:41:44 GMT, Radim Vansa <duke at openjdk.org> wrote:

>> inotify monitors changes on filesystem, this support automatic restore for LinuxFileWatcher.
>> 
>> FileWatcherAfterRestoreTest verifies watcher service works after restore.
>> FileWatcherTest verifies automatic closing inotiify fd
>> 
>> The watcher keys are still managed by user, so exception will be thrown if no watcher keys are leaked, as in FileWatcherWithOpenKeysTest
>
> Can't tell out of top of my head - the crash.log has the VM error log printed just after calling `ls` rather than `java -ea -XX:CRaCCheckpointTo=cr jdk.test.lib.crac.CracTest __run_test__ FileWatcherAfterRestoreTest` - have you edited it?
> 
> Could you try to reproduce with a `CONF=fastdebug` build?

@rvansa , sorry, looks like I accidentally paste some of the bash histories in gist, the error is caused by `java -ea -XX:CRaCCheckpointTo=cr jdk.test.lib.crac.CracTest __run_test__ FileWatcherAfterRestoreTest` .

And here is the `fastdebug` level [crash log ](https://gist.github.com/joeyleeeeeee97/42711c35e02b0d2c530bad22aa2c5dd0).

And I am not editing any related logic, this happens after the restored process finished execution and start exiting.

V  [libjvm.so+0x8d4275]  oop RawAccessBarrier<594020ul>::oop_load<oop>(void*)+0x15
V  [libjvm.so+0x8d4905]  AccessInternal::PostRuntimeDispatch<G1BarrierSet::AccessBarrier<594020ul, G1BarrierSet>, (AccessInternal::BarrierType)2, 594020ul>::oop_access_barrier(void*)+0x15
V  [libjvm.so+0x137d20b]  ObjectMonitor::object_peek() const+0x1b
V  [libjvm.so+0x1798354]  ObjectSynchronizer::release_monitors_owned_by_thread(JavaThread*)+0xf4
V  [libjvm.so+0x180f447]  JavaThread::exit(bool, JavaThread::ExitType)+0x8d7
V  [libjvm.so+0xe91a4d]  jni_DetachCurrentThread+0x8d
C  [libjli.so+0x4c71]  JavaMain+0xc41
C  [libjli.so+0x7a19]  ThreadJavaMain+0x9

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

PR Comment: https://git.openjdk.org/crac/pull/72#issuecomment-1548926529