RFR: 8359706: Add file descriptor count to VM.info [v8]

[Thomas Stuefe]

On Tue, 20 Jan 2026 19:53:41 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms.
>> 
>> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor updates

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

> 2587: #ifdef __APPLE__
> 2588:   const int MAX_SAFE_FDS = 1024;
> 2589:   struct proc_fdinfo fds[MAX_SAFE_FDS];

Hmm, this may be a bad idea. This function is called during signal handling. Don't allocate massive amounts of stack storage here, that may lead to secondary crashes during error handling which we could not recover from.

See below, I am not sure it is even necessary.

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

> 2606: 
> 2607:   nfiles = res / sizeof(struct proc_fdinfo);
> 2608:   if (nfiles >= MAX_SAFE_FDS) {

About MAX_SAFE_FDS:

What is really returned by `pid_for_task`? 

If return values > MAX_SAFE_FDS are possible, would that be the reliable "number of open fds" ? If so, why not print that instead of ">1024"? In fact, if so, why even bother returning an array at all, why not make the array 1-element-sized only, pro format? All we are interested in is the number.

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

> 2613:   st->print_cr("Open File Descriptors: %d", nfiles);
> 2614: #else
> 2615:     st->print_cr("Open File Descriptors: unknown");

Indentation looks off

Also, the code could be condensed quite a bit.

src/hotspot/os/linux/os_linux.cpp line 5406:

> 5404:     if (isdigit(dentp->d_name[0])) fds++;
> 5405:     if (fds % 100 == 0) {
> 5406:       clock_gettime(CLOCK_MONOTONIC, &now);

You don't query the return code here. If clock_gettime fails, content of `now` is undefined. Could lead to premature abortion of this loop.

If runtime errors are possible, they should be handled; otherwise an assertion would be the right thing to do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2759298203
PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2759274151
PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2759277532
PR Review Comment: https://git.openjdk.org/jdk/pull/27971#discussion_r2759289309