JDK-8324577 : [REDO] - [IMPROVE] OPEN_MAX is no longer the max limit on macOS >= 10.6 for RLIMIT_NOFILE
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 21
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • Submitted: 2024-01-24
  • Updated: 2024-11-01
  • Resolved: 2024-04-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17 JDK 21 JDK 23
17.0.13Fixed 21.0.5-oracleFixed 23 b20Fixed
Related Reports
Blocks :  
JDK-8324668 - JDWP process management needs more efficient file descriptor handling
Cloners :  
JDK-8300088 - [IMPROVE] OPEN_MAX is no longer the max limit on macOS >= 10.6 for RLIMIT_NOFILE
Relates :  
JDK-8343285 - java.lang.Process is unresponsive and CPU usage spikes to 100%
Relates :  
JDK-8291060 - OPEN_MAX is no longer the max limit on macOS >= 10.6 for RLIMIT_NOFILE
Relates :  
JDK-8299258 - Launching ksh (shell) from within Java through ProcessBuilder causes ksh process to crash with EXC_BAD_ACCESS (SIGSEGV)
Sub Tasks
JDK-8324578 :  
[BACKOUT] [IMPROVE] OPEN_MAX is no longer the max limit on macOS >= 10.6 for RLIMIT_NOFILE - Closed
Description
Redo of JDK-8300088 

This will track an improvement of JDK-8291060 "OPEN_MAX is no longer the max limit on macOS >= 10.6 for RLIMIT_NOFILE" taking into the account what we learned from JDK-8299258 "Launching ksh (shell) from within Java through ProcessBuilder causes ksh process to crash with EXC_BAD_ACCESS (SIGSEGV)"

The reason I would like to see this properly fixed, is that I would like to see parity of macOS and Linux when it comes to process/file count as it might be important to the os behavior under MACH5 and explain the issues we see on macOS compared to other platforms. This is just one tiny piece in a big puzzle and I would like to know that it's in the right spot.
Comments
This change https://github.com/openjdk/jdk/pull/18821/files exposed a bug in gdb resulting in an attempt to launch gdb hanging seemingly forever. The relevant code can be found here: https://github.com/bminor/binutils-gdb/blob/893e4fd6231922495175b701a6c44b665e91cd7e/gdbsupport/filestuff.cc#L154C23-L154C26 It loops over *all* file descriptors available to the process at startup, so having INT_MAX there makes the loop take a very long time: { #ifdef _SC_OPEN_MAX max = sysconf (_SC_OPEN_MAX); #else /* Whoops. */ return 0; #endif /* _SC_OPEN_MAX */ } for (fd = 0; fd < max; ++fd) { struct stat sb; int result; /* Only call FUNC for open fds. */ if (fstat (fd, &sb) == -1) continue; result = func (arg, fd); if (result != 0) return result; }
01-11-2024
This fix has caused existing applications to hang. See JDK-8343285. java.lang.Process is unresponsive and CPU usage spikes to 100% It should NOT be backported and possibly reversed in the backports due to the incompatibility it causes. A new fix will be needed.
01-11-2024
[jdk17u-fix-request] Approval Request from Dmitry Cherepanov Sets higher macOS limit for file descriptions. Clean backport. Passes local tier1-4 testing in macos-aarch64.
17-06-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/2595 Date: 2024-06-17 07:46:09 +0000
17-06-2024
[jdk21u-fix-request] Approval Request from Martin Should get backported for parity with 21.0.5-oracle. Applies cleanly and tier 1-4 have passed.
03-06-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/640 Date: 2024-05-31 19:22:29 +0000
31-05-2024
Changeset: f1d0e715 Author: Gerard Ziemski <gziemski@openjdk.org> Date: 2024-04-24 14:27:10 +0000 URL: https://git.openjdk.org/jdk/commit/f1d0e715b67e2ca47b525069d8153abbb33f75b9
24-04-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/18821 Date: 2024-04-17 16:49:25 +0000
19-04-2024
According to the latest tier1-9 Mach5 test none of the failures involve macOS, which is the only platform affected, so this should give us a high confidence that we can proceed with this fix.
15-04-2024
I didn't notice that you ran hs-tier1-8. I keep telling people not to limit their pre-integration testing to the hs-tiers. The previous version of this fix had failures in tier3, tier5, tier6, and tier8. I strongly recommend Tier{1-8} testing for this fix considering the backout history.
28-03-2024
Same fix as in JDK-8291060, just with more testing.
02-02-2024
Still would like to see it fixed, taking into account the recent failure (internal testing in jdwp) and the previous one (ksh) Summary: - failure in ksh was due to a bug in ksh where the MAX value was overflowing the internal variable - failure in jdwp was due to an issue, where jdwp was closing all file descriptors inherited from a parent process and since we increased the limit, it now times out trying to close them all.
24-01-2024