From f1d0e715b67e2ca47b525069d8153abbb33f75b9 Mon Sep 17 00:00:00 2001 From: Gerard Ziemski Date: Wed, 24 Apr 2024 14:27:10 +0000 Subject: [PATCH] 8324577: [REDO] - [IMPROVE] OPEN_MAX is no longer the max limit on macOS >= 10.6 for RLIMIT_NOFILE Reviewed-by: dcubed, dholmes --- src/hotspot/os/bsd/os_bsd.cpp | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/src/hotspot/os/bsd/os_bsd.cpp b/src/hotspot/os/bsd/os_bsd.cpp index 4b849c5bad4..ca4a77d2b4a 100644 --- a/src/hotspot/os/bsd/os_bsd.cpp +++ b/src/hotspot/os/bsd/os_bsd.cpp @@ -2140,16 +2140,25 @@ jint os::init_2(void) { if (status != 0) { log_info(os)("os::init_2 getrlimit failed: %s", os::strerror(errno)); } else { - nbr_files.rlim_cur = nbr_files.rlim_max; + rlim_t rlim_original = nbr_files.rlim_cur; -#ifdef __APPLE__ - // Darwin returns RLIM_INFINITY for rlim_max, but fails with EINVAL if - // you attempt to use RLIM_INFINITY. As per setrlimit(2), OPEN_MAX must - // be used instead - nbr_files.rlim_cur = MIN(OPEN_MAX, nbr_files.rlim_cur); -#endif + // On macOS according to setrlimit(2), OPEN_MAX must be used instead + // of RLIM_INFINITY, but testing on macOS >= 10.6, reveals that + // we can, in fact, use even RLIM_INFINITY, so try the max value + // that the system claims can be used first, same as other BSD OSes. + // However, some terminals (ksh) will internally use "int" type + // to store this value and since RLIM_INFINITY overflows an "int" + // we might end up with a negative value, so cap the system limit max + // at INT_MAX instead, just in case, for everyone. + nbr_files.rlim_cur = MIN(INT_MAX, nbr_files.rlim_max); status = setrlimit(RLIMIT_NOFILE, &nbr_files); + if (status != 0) { + // If that fails then try lowering the limit to either OPEN_MAX + // (which is safe) or the original limit, whichever was greater. + nbr_files.rlim_cur = MAX(OPEN_MAX, rlim_original); + status = setrlimit(RLIMIT_NOFILE, &nbr_files); + } if (status != 0) { log_info(os)("os::init_2 setrlimit failed: %s", os::strerror(errno)); }