Self-Reflection of Java Performance Profile

Introspecting Instrumented Java using the Probes Open API

One of the more powerful aspects of the Probes Open API is the ability to introspect on the metering of instrumented methods executed by a thread. With this, a method can in effect ask itself “what is it that I do?” post the execution of some code block. This is achieved via metering ChangeSets.

Java already supports the ability to introspect on structure and to use such information to invoke behavior but it cannot self-reflect on such invocation.

Let’s take a small simple piece of code to demonstrate the runtime reflection capabilities offered by a metering engine with full Probes Open API support.

Can the main() method be enhanced such that it can itself introspect on the call count and clock timing of methods executed with the scope of the loop?

SavePoints and ChangeSets

To reflect on the code execution occurring within the loop, including direct and nested method calls, grab the current thread Context, before entering the loop create a metering SavePoint, then following the termination of the loop generate a metering ChangeSet using the method.

The above can be shortened with an import static statement, as all the interfaces are enclosed within the Probes class — the only class in the API.

With the ChangeSet, it is possible to introspect the call count for a method. Simply, look up the ChangePoint for a method. Check if is present in the set as it might not have been called or metered. Then retrieve the Change for the measure, clock.time, metered by the metering engine via the JVM agent.

The console output listing the metered call count for the ingress() method.

The ChangeSet can be used to iterate over all probes metered during the execution window demarcated by the savepoint() and compare() call sites.

With Java 8 the above can be made significantly more concise and readable.

Here is the console output with the Satoris instrumentation agent installed.

There’s no need to change the original sources to introduce such reflective reporting of metered performance within the execution scope of a thread. Instead use the interception mechanism supported in the Probes Open API.

The printed console out with an extra name included — the main() method.


The reflective capabilities of the Probes Open API are extremely powerful and have numerous potential use cases. It can be used to append metering profile information to outbound HTTP responses, to detect underlying behavioral changes across software releases or in the course of execution, to collect and store charge/show back data for each service request, as well as improve performance unit testing within a continuous integration pipeline.