RFR: 8359706: Add file descriptor count and maximum limit to VM.info

[Thomas Stuefe]

On Fri, 24 Oct 2025 08:25:21 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.

Hmm. Not 100% convinced we should do it this way, at least not in hs-err files where speed is somewhat important. But let's see.

File descriptor counting scales linearly with the number of open files. Process can have in the 100000 range of open files in case of leaks, and those cases are the interesting ones. On slow boxes this can hurt.

The problem can be somewhat mitigated by making the counting dependent on kernel FDSize in case of Linux. If that is very large, maybe don't count. But that is Linux only. AIX file ops can be pretty slow. Plus, AIX does not show all file descriptors in /proc.

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

PR Comment: https://git.openjdk.org/jdk/pull/27971#issuecomment-3450788627