RFR: 8343285: java.lang.Process is unresponsive and CPU usage spikes to 100%
Gerard Ziemski
gziemski at openjdk.org
Fri Nov 8 19:35:58 UTC 2024
We lower the max value of allowed file descriptors on macOS to match that of Linux, i.e. 0x100000 (1,048,576).
Background:
On JDK22 and earlier the limit on maximum number of file descriptors allowed in Java process on macOS was 10,240. We increased it in jdk23 to unlimited value (MAX_LONG), as allowed by the os, but that caused a crash in KSH, so we then lowered it to MAX_INT (so it wouldn't overflow an int).
Then we noticed that we had code in jdwp agent that would iterate over all allowed file descriptors trying to close them all, which would time out internal tests, because it was taking so long. We fixed this in jdwp, so that we only close actual opened file descriptors - see https://github.com/openjdk/jdk/commit/a6632487863db5ff3136cdcc76b7440c15ce6be9#diff-1a48137c6688c91d10f931b3e37e4b961b24748fbcb2906d629807aea53db80fR71
However, there are other external jdk clients, that do the exact same thing and their java processes also appear to hang closing all allowed file descriptors.
Since `MaxFDLimit` is ON by default, we have no other choice, but to lower the value, so it doesn't cause regressions. With this new max value, closing all file descriptors on an old x86_64 machine takes under 1 second on macOS (and Linux).
Testing: in progress...
-------------
Commit messages:
- llimit max file descriptors to 0x100000, same as on Linux
Changes: https://git.openjdk.org/jdk/pull/21992/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21992&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8343285
Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod
Patch: https://git.openjdk.org/jdk/pull/21992.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21992/head:pull/21992
PR: https://git.openjdk.org/jdk/pull/21992
More information about the hotspot-runtime-dev
mailing list