On Thu, 8 Jan 2026 19:19:37 GMT, Kieran Farrell <[email protected]> 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 with a new target base due to a 
> merge or a rebase. The pull request now contains 23 commits:
> 
>  - Merge branch 'openjdk:master' into JDK_8359706
>  - comment
>  - timed loop for aix and linux proc read
>  - rm unused variables
>  - updates
>  - clean up
>  - clean up
>  - undo commit to linux.cpp
>  - rm max count and malloc
>  - bsd.cpp
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/1342db0b...1f34d255

Hi - Could you include an example of what this looks like in context, an 
excerpt from the whole output showing the new info in context?

It's between "printing heap information" and "printing GC information", which 
might be a bit odd as those things should stay grouped together for humans to 
read?

Would it be a better fit in the "OS:" section which is where we show e.g. limit 
information.

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

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

Reply via email to