Some Kubernetes setups share the /tmp directory across multiple containers. On rare occasions, the JVM may crash when it tries to write to `/tmp/hsperfdata_<user>/<pid>` when a process in a separate container decides to do the same thing (because they happen to have the same namespaced pid).
This patch avoids the crash by using `flock()` to allow only one of these processes to write to the file. All other competing processes that fail to grab the lock will give up the file and run with PerfMemory disabled. We will try to enable PerfMemory for the failed processes in a follow-up RFE: [JDK-8289883](https://bugs.openjdk.org/browse/JDK-8289883) Thanks to Vitaly Davidovich and Nico Williams for coming up with the idea of using `flock()`. I kept the use of `kill()` for stale file detection to be compatible with older JVMs. I also took the opportunity to clean up the comments and remove dead code. The old code was using "shared memory resources" which sounds unclear and odd. I changed the terminology to say "shared memory file" instead. ------------- Commit messages: - Merge branch 'master' into 8286030-avoid-jvm-crash-when-containers-share-tmp-dir - Cleaned up comments and avoid using the word "resource" to describe the shared mem file - fixed comments - Added test case - fix timing hole -- another JVM process can create file while I am trying to delete - working - temp-not-working Changes: https://git.openjdk.org/jdk/pull/9406/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9406&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286030 Stats: 286 lines in 3 files changed: 238 ins; 21 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/9406.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9406/head:pull/9406 PR: https://git.openjdk.org/jdk/pull/9406
