8324577: [REDO] - [IMPROVE] OPEN_MAX is no longer the max limit on macOS >= 10.6 for RLIMIT_NOFILE

Reviewed-by: dcubed, dholmes
This commit is contained in:
Gerard Ziemski 2024-04-24 14:27:10 +00:00
parent 74b11ccf14
commit f1d0e715b6

@ -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));
}