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

[David Holmes]

On Thu, 11 Jan 2024 17:08:47 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:
> 
>   ksh bug affects all BSD platforms

Revised structure looks good. Just some minor suggestions. Thanks.

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

> 2040:       log_info(os)("os::init_2 getrlimit failed: %s", os::strerror(errno));
> 2041:     } else {
> 2042:       rlim_t rlim_org = nbr_files.rlim_cur;

Nit: can you use `rlim_orig` instead of `rlim_org` please.

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

> 2052:       // we might end up with a negative value, so cap the system limit max
> 2053:       // at INT_MAX instead, just in case, for everyone.
> 2054:       nbr_files.rlim_cur = MIN(INT_MAX, nbr_files.rlim_max);

You can combine this into one comment block and one assignment:

// ...
// that the system claims can be used first, same as other BSD OSes.
// However, some terminals (ksh) will internally use "int" type
// ...
nbr_files.rlim_cur = MIN(INT_MAX, nbr_files.rlim_max);

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17361#pullrequestreview-1817462792
PR Review Comment: https://git.openjdk.org/jdk/pull/17361#discussion_r1449887474
PR Review Comment: https://git.openjdk.org/jdk/pull/17361#discussion_r1449886593