Proposal: Expand Filesystem JFR Events

[Marius Volkhart]

Hi devs,

OpenJDK already has built-in JFR events for file reads and write. However, there are a variety of additional file system interactions that are not instrumented, despite their potential impact on application performance. I would like to contribute changes that expand the built-in instrumentation to cover these interactions. I am in search of a sponsor and folks interested who might have opinions or use cases they can share.

Examples of these interactions include checking if the file exists, creating a directory, creating a symlink, and reading file attributes.

One of the design questions for something like this is, which Event to use? For example, reading and writing file attributes could be reported as a jdk.FileRead and jdk.FileWrite. However, this might muddy the waters, especially as we get to interactions like creating a directory or symlink. Here, the byte count is unknown.

Alternatively, a new event could be created. This event might report only that a file interaction occurred, but not go into further details about data count. This is likely still enough information for developers to act upon.

A concrete example comes from my day job. The desktop application in question works with user files, and customers of this app are very IO-sensitive, due to frequently using network shares and virtualized desktops. A recent dependency update caused a jump in IOPS. This was caught pre-release by Windows OS tooling, but JFR didn’t show any immediate problems. However, digging into the changes revealed that the new dependency versions was calling Files.exists(Path), Files.isRegularFile(Path), and getting file attributes far more often than the previous version.

I’ve done a bit of prototyping and research on the JFR code. At a high level, I think these changes include
- Instrumenting various subclasses of sun.nio.fs.AbstractFileSystemProvider
- Instrumenting various subclasses of java.io.FileSystem
- Modifying JFR instrumentation code to handle the differences between these types and previously instrumented types. Differences include platform-specific implementation classes, and leaf-classes that don’t define all the methods being instrumented.

I have OpenJDK building and have used jtreg before, but this would be only my second contribution, so I am very much still a beginner on OpenJDK tooling and process. Still if folks show interest and a sponsor presents themselves, I’m happy to break down this admittedly large-scoped proposal into smaller chunks with more details and concrete questions/decisions.

Cheers,
Marius Volkhart