RFR: 8300088: [IMPROVE] OPEN_MAX is no longer the max limit on macOS >= 10.6 for RLIMIT_NOFILE [v3]

[Daniel D. Daugherty]

On Fri, 12 Jan 2024 20:09:34 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> On current macOS (> 10.6) we can use `RLIM_INFINITY` for `setrlimit(RLIMIT_NOFILE)`, even though the man page for setrlimit(2) claims otherwise.
>> 
>> The only wrinkle here is that some terminals (ksh) will crash with `RLIM_INFINITY`, because that value overflows `int` type, which they use internally, causing crash, so we work around that by using `INT_MAX` instead of `RLIM_INFINITY`.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David's feedback

Just a couple of nit typos. Otherwise, thumbs up.
Don't forget to check for a copyright year update.

What's the current value of `OPEN_MAX` and `INT_MAX`
on macOS these days?

src/hotspot/os/bsd/os_bsd.cpp line 2044:

> 2042:       rlim_t rlim_original = nbr_files.rlim_cur;
> 2043: 
> 2044:       // on macOS according to setrlimit(2), OPEN_MAX must be used instead

Nit typo: s/on macOS/On macOS/

src/hotspot/os/bsd/os_bsd.cpp line 2056:

> 2054:       status = setrlimit(RLIMIT_NOFILE, &nbr_files);
> 2055:       if (status != 0) {
> 2056:         // if that fails then try lowering the limit to either OPEN_MAX

nit typo: s/if that/If that/

-------------

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17361#pullrequestreview-1830627317
PR Review Comment: https://git.openjdk.org/jdk/pull/17361#discussion_r1458022038
PR Review Comment: https://git.openjdk.org/jdk/pull/17361#discussion_r1458023061