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:
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));
|
||||
}
|
||||
|
Loading…
x
Reference in New Issue
Block a user