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

kieran-farrell · 2025-10-24T08:25:21Z

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.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8359706: Add file descriptor count and maximum limit to VM.info (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27971/head:pull/27971
$ git checkout pull/27971

Update a local copy of the PR:
$ git checkout pull/27971
$ git pull https://git.openjdk.org/jdk.git pull/27971/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27971

View PR using the GUI difftool:
$ git pr show -t 27971

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27971.diff

Using Webrev

Link to Webrev Comment

# Conflicts: # src/hotspot/os/windows/os_windows.cpp

bridgekeeper · 2025-10-24T08:26:49Z

👋 Welcome back kfarrell! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-10-24T08:27:50Z

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

openjdk · 2025-10-24T08:28:39Z

@kieran-farrell The following label will be automatically applied to this pull request:

hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2025-10-24T08:32:34Z

Webrevs

jsikstro

I'm not 100% sure about the placement in the VMError::print_vm_info, but some comments so far.

jsikstro · 2025-10-27T11:05:53Z

src/hotspot/os/bsd/os_bsd.cpp

+#ifdef __APPLE__
+void os::print_open_file_descriptors(outputStream* st) {
+  const int MAX_SAFE_FDS = 1024;
+  struct proc_fdinfo fds[MAX_SAFE_FDS];
+  struct proc_bsdinfo bsdinfo;
+  int nfiles;
+  kern_return_t kres;
+  int res;
+  size_t fds_size;
+  pid_t my_pid;
+
+  kres = pid_for_task(mach_task_self(), &my_pid);
+  if (kres != KERN_SUCCESS) {
+    st->print_cr("OpenFileDescriptorCount = unknown");
+    return;
+  }
+
+  res = proc_pidinfo(my_pid, PROC_PIDLISTFDS, 0, fds, MAX_SAFE_FDS * sizeof(struct proc_fdinfo));
+  if (res <= 0) {
+    st->print_cr("OpenFileDescriptorCount = unknown");
+    return;
+  }
+
+  nfiles = res / sizeof(struct proc_fdinfo);
+  if (nfiles >= MAX_SAFE_FDS) {
+    st->print_cr("OpenFileDescriptorCount = unknown");
+    return;
+  }
+
+  st->print_cr("OpenFileDescriptorCount = %d", nfiles);
+}
+#endif // __APPLE__
+
+#if defined(_ALLBSD_SOURCE) && !defined(__APPLE__)
+long os::get_open_file_descriptor_count() {
+    st->print_cr("OpenFileDescriptorCount = unknown");
+}
+#endif


Is defined(_ALLBSD_SOURCE) needed? The return type for the non-apple variant is incorrect. Maybe we could do something like the following here instead:

void os::print_open_file_descriptors(outputStream* st) { #ifdef __APPLE__ // do Apple stuff #else st->print_cr("OpenFileDescriptorCount = unknown"); #endif }

jsikstro · 2025-10-27T11:05:57Z

src/hotspot/share/utilities/vmError.cpp

+  // STEP("printing number of open file descriptors")
+  #ifndef _WIN32
+    os::print_open_file_descriptors(st);
+    st->cr();
+  #endif
+


This is in VMError::print_vm_info which is only printed via the VM.info jcmd and the -XX:+PrintVMInfoAtExit flag. To add it to hs_err files, you should also add the code to VMError::report.

jsikstro · 2025-10-27T11:08:13Z

src/hotspot/os/linux/os_linux.cpp

+      }
+    }
+    closedir(dirp);
+    st->print_cr("OpenFileDescriptorCount = %d", fds - 1);


Maybe a comment on why we do -1 here, like you have for the AIX implementation.

tstuefe · 2025-10-27T11:22:30Z

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.

jsikstro · 2025-10-29T14:47:44Z

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?

jsikstro

Just FYI, you can test what's being printed in hs_err files easily by using the -XX:ErrorHandlerTest=14 flag, which crashes the VM in a "controlled way".

jsikstro · 2025-10-29T14:08:21Z

src/hotspot/os/bsd/os_bsd.cpp

+#ifdef __APPLE__
+  const int MAX_SAFE_FDS = 1024;
+  struct proc_fdinfo fds[MAX_SAFE_FDS];
+  struct proc_bsdinfo bsdinfo;


jsikstro · 2025-10-29T14:08:23Z

src/hotspot/os/bsd/os_bsd.cpp

+  int nfiles;
+  kern_return_t kres;
+  int res;
+  size_t fds_size;


tstuefe · 2025-10-29T15:56:35Z

Just to be clear, number of open files is a very useful metric. I would see no problem adding this to VM.info and hs-err file, but we need some failsafe in case iteration takes too long. Can be very simple as in "every n iterations check time for limit).

kieran-farrell · 2025-10-30T19:39:46Z

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 and what would be an acceptable threshold? 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?

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

kieran-farrell added 18 commits October 23, 2025 22:03

added platform logger

8b78feb

updated platform logger

d48a20f

updated platform logger

1794ca1

updated platform logger

a4e451f

loggign

204c783

add open fd method

af4c66c

add to vmError

a0185ac

updates

ccecd6c

rm files

be54098

rm classloader

a72e97b

replace NULL

701f20e

# Conflicts: # src/hotspot/os/windows/os_windows.cpp

change to print outs

1ea8863

update

67b9131

bsd.cpp

0663271

rm max count and malloc

0d8d72d

undo commit to linux.cpp

14dca9c

clean up

d796913

clean up

2d2acfe

openjdk bot added the hotspot [email protected] label Oct 24, 2025

openjdk bot added the rfr Pull request is ready for review label Oct 24, 2025

jsikstro reviewed Oct 27, 2025

View reviewed changes

updates

d51b07a

jsikstro reviewed Oct 29, 2025

View reviewed changes

rm unused variables

bd00e39

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

Are you sure you want to change the base?

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

Conversation

kieran-farrell commented Oct 24, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewing

Uh oh!

bridgekeeper bot commented Oct 24, 2025

Uh oh!

openjdk bot commented Oct 24, 2025

Uh oh!

openjdk bot commented Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge bot commented Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

jsikstro left a comment

Choose a reason for hiding this comment

Uh oh!

jsikstro Oct 27, 2025

Choose a reason for hiding this comment

Uh oh!

jsikstro Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsikstro Oct 27, 2025

Choose a reason for hiding this comment

Uh oh!

tstuefe commented Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jsikstro commented Oct 29, 2025

Uh oh!

jsikstro left a comment

Choose a reason for hiding this comment

Uh oh!

jsikstro Oct 29, 2025

Choose a reason for hiding this comment

Uh oh!

jsikstro Oct 29, 2025

Choose a reason for hiding this comment

Uh oh!

tstuefe commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kieran-farrell commented Oct 30, 2025

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

kieran-farrell commented Oct 24, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Oct 24, 2025 •

edited

Loading

mlbridge bot commented Oct 24, 2025 •

edited

Loading

jsikstro Oct 27, 2025 •

edited

Loading

tstuefe commented Oct 27, 2025 •

edited

Loading

tstuefe commented Oct 29, 2025 •

edited

Loading