P3
A reoccurring request over the years has been a way to use JFR to trace method invocations. Users typically have a method in their application that they like to know where and when it was invoked.
One incarnation of this problem is to locate where threads are started. It was fixed recently by adding a stack trace to the ThreadStart event, but there are other methods than Thread.start() that users want to troubleshoot.
The main problem has been how to configure such a system. Should you specify the methods you want to trace using a DSL, XML or perhaps a properties file where you list the methods? Since we now provide a public API, a Java agent could be implemented easily to do this using a configuration scheme deemed appropriate. In fact, JMC already has a Java agent where you can specify methods using XML.
That said, once we have fixed Parameterized Event Configuration and cheaper stack traces, it may make sense to see if we could make something that could easily be specified on command line or using jcmd.
Imagine an event that could be configured like this:
<event name="jdk.MethodTrace">
<setting name="enabled">true</setting>
<setting name="stackTrace">true</setting>
<setting name="methods">java.util.Hashmap.resize()</setting>
</event>
It would take the stack trace and measure the time it takes for HashMap.resize() to execute. With Event Metrics (see JDK-8224749) it would also be possible to measure CPU utilization and the amount of memory that was allocated in a traced method.
Parameterized Event Configuration could provide means to make this available on command line or jcmd, so a user could do:
$ java -XX:StartFlightRecording:method-trace=java.util.HashMap.resize()
or
$ jcmd <pid> JFR.start method-trace=System.gc() duration=8s filename=rec.jfr
The result could be seen in JMC or using the 'jfr' tool:
$ jfr print -events MethodTrace rec.jfr
The overhead could be enormous if a hot method is traced. It would be the users responsibility to not trace such methods in production environments.
Multiple methods could be specified using a delimiter, for example "java.util.HashMap.resize():System.gc()". If the user specifies an interface, it would be nice if all implementation classes were instrumented. An initial version may ignore interfaces, as it may be trickier to implement.
One incarnation of this problem is to locate where threads are started. It was fixed recently by adding a stack trace to the ThreadStart event, but there are other methods than Thread.start() that users want to troubleshoot.
The main problem has been how to configure such a system. Should you specify the methods you want to trace using a DSL, XML or perhaps a properties file where you list the methods? Since we now provide a public API, a Java agent could be implemented easily to do this using a configuration scheme deemed appropriate. In fact, JMC already has a Java agent where you can specify methods using XML.
That said, once we have fixed Parameterized Event Configuration and cheaper stack traces, it may make sense to see if we could make something that could easily be specified on command line or using jcmd.
Imagine an event that could be configured like this:
<event name="jdk.MethodTrace">
<setting name="enabled">true</setting>
<setting name="stackTrace">true</setting>
<setting name="methods">java.util.Hashmap.resize()</setting>
</event>
It would take the stack trace and measure the time it takes for HashMap.resize() to execute. With Event Metrics (see JDK-8224749) it would also be possible to measure CPU utilization and the amount of memory that was allocated in a traced method.
Parameterized Event Configuration could provide means to make this available on command line or jcmd, so a user could do:
$ java -XX:StartFlightRecording:method-trace=java.util.HashMap.resize()
or
$ jcmd <pid> JFR.start method-trace=System.gc() duration=8s filename=rec.jfr
The result could be seen in JMC or using the 'jfr' tool:
$ jfr print -events MethodTrace rec.jfr
The overhead could be enormous if a hot method is traced. It would be the users responsibility to not trace such methods in production environments.
Multiple methods could be specified using a delimiter, for example "java.util.HashMap.resize():System.gc()". If the user specifies an interface, it would be nice if all implementation classes were instrumented. An initial version may ignore interfaces, as it may be trickier to implement.