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

[Thomas Stuefe]

On Wed, 29 Oct 2025 14:47:44 GMT, Joel Sikström <jsikstro at openjdk.org> wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates
>
>> 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 
> 
> I'm trying to understand what functionality you're after here. Is the specific number of open file descriptors important or is it enough to just report that there are "a lot" of file descriptors open? If so, @tstuefe's suggested approach of looking at `/proc/self/status` and FDSize and don't report the exact number if over some limit is a good compromise I think.
> 
> I couldn't find any good documentation for Mac's `proc_pidinfo`, but looking at the source code it's not an expensive operation at all (https://github.com/apple/darwin-xnu/blob/2ff845c2e033bd0ff64b5b6aa6063a1f8f65aa32/bsd/kern/proc_info.c#L486). I know very little of AIX to have an opinion, but if it's an issue maybe we can skip reporting it for now?

> Thanks @jsikstro and @tstuefe for the insightful comments. Just to note, the maximum possible FDs (NOFILE) is already printed in VM.info (and maybe should be added to the hs_err file), the main idea of this patch is to provide the current number of open file descriptors for diagnosing FD exhaustion (compared against the max FD) and FD leaks.
> 
> Would a timed loop for both AIX and Linux (exiting the scan if it takes more than a set threshold) work 

that would be my preferred solution

> and what would be an acceptable threshold? 

A few ms; 50 maybe?

> Maybe we could report that the FD count above the current counted value if we reach the threshold or fall back to reporting the FDSize field from /proc/self/status on Linux as a rough estimate?

I would not put any work into this. Just report what you got, as in ">10000" or somesuch. If this time limit hits, we have a ton of file descriptors, or something is wrong with /proc; either is rare. The exact number does not matter then. An analyst would probably have to look at the machine or the VM process to check what's going on. E.g. who opens that many files.

> 
> Also, the Mac API is undocumented - https://zameermanji.com/blog/2021/8/1/counting-open-file-descriptors-on-macos/.

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

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