Experimenting with jfr mirror events – Inside.java

submited by
Style Pass
2021-06-04 18:30:07

This writeup describes a number of observations while performing an experiment to determine the feasibility of using JFR mirror events in core parts of the JDK, in particular, the Networking APIs. Mirror events are an internal mechanism used by the JDK that does not depend on the jdk.jfr module, currently the only mirror events are defined in java.base. Since mirror events are only available within the JDK, much of what is discussed within is directly relevant to developers working on the JDK (rather than application or library developers), but certain concerns and techniques may be of interest to the wider audience.

When implementing events within the JDK, and specifically within the base module, there are currently a number of approaches: 1) a native implementation in the JVM, or 2) bytecode instrumentation at run time, or 3) a mirror event. The first, a native implementation in the JVM, is most appropriate for low-level operations of the JVM itself, e.g. GC statistics. For monitoring the JDK Core libraries the latter two approaches, bytecode instrumentation or a mirror event are more appropriate. But which approach is better, and what are the trade-offs between them? By taking one particular event as an example, this writeup offers some insights and analysis to help answer that question.

Currently (in JDK 17), there are JFR events that allow monitoring socket read and write operations. Namely, jdk.SocketReadEvent and jdk.SocketWriteEvent, respectively. These events are capable of monitoring I/O of both java.net.Socket and NIO SocketChannel. Looking at the source code of the socket or channel implementations there is no reference to JFR or these events, but the code related to the generation of said events is performed through bytecode instrumentation (of the socket and channel implementation classes) at run time, when JFR is enabled. We’ll first generate performance data when recording the existing socket write event, then when reimplemented as a mirror event, and finally we’ll look at areas for potential improvements.

Leave a Comment