Writing a Profiler in 240 lines of pure Java

https://mostlynerdless.de/blog/2023/03/27/writing-a-profiler-in-240-lines-of-pure-java/

by mfiguiere • 3 years ago

156 29 3 years ago

omazurov2• 3 years ago

Profilers are not rocket science...

They are not. There are orders of magnitude more rocket scientists than good profiler writers. And no, bottle rockets with flight recorders do not count.

hardware2win• 3 years ago

"It is not rocket science" is so 1970, I'd say nowadays it is "It is not semiconductor eng."

chrsig• 3 years ago

What is your criteria for 'good profiler writer'?

timcobb• 3 years ago

I know one when I see one

parttimenerd10• 3 years ago

The number of profiler writers is not too large (if you ignore all the people writing the UIs), but it's the same with compilers: You only need a few to create a useful enough product. There are many more people working on tracing right now.

There are even fewer people working on the underlying profiling APIs. I'm one of the few working regularly on the stack walking API that powers most Application Platform Monitors (and async-profiler). I'm the person who writes all the code to test AsyncGetCallTrace currently. If anyone is interested: I wrote a blog post on it https://mostlynerdless.de/blog/2023/03/14/validating-java-pr....

I'm writing blog posts on the profiling topic every two weeks (usually publishing them on Monday or Tuesday).

jpgvm2• 3 years ago

Such a task is usually thankless work so, thank you. :)

I don't doubt my favorite profiler, YourKit also uses your code.

Profilers are probably the class of tool that most drastically improved the code I write so if anyone reading hasn't really felt the need to use one, you should.

Just a cursory glance can quickly verify assumptions about runtime performance. Even if the code is currently acceptable it helps to be mindful of where cycles are being spent (and lock contention, network blocking, etc) so if you end up doing some refactoring anyway that additional context and knowledge can guide improvements that aren't strictly "performance work".

grumpyprole2• 3 years ago

This of course relies on Java's reflection ability, in this case, an API to retrieve stack traces for all threads dynamically. An interesting question is how this is implemented and how regular invocation might affect the runtime (e.g. global locks).

parttimenerd10• 3 years ago

(Author here) It's not about Java's ability to do reflection, many languages expose the ability to get stack-traces. It's usually used for logging and exceptions. But I could certainly write a blog post on how stack-walking is implemented for the likes of async-profiler, as I'm currently working on a new stack-walking API for Java (JEP 435).

grumpyprole2• 3 years ago

It's usually used for logging and exceptions.

That's why I was querying it's suitability for profiling. The time to get a lock for a global "safepoint" and then release it must be significant no?

parttimenerd10• 3 years ago

(Author here) This blog post is actually part of a series to write profilers from scratch (https://mostlynerdless.de/blog/tag/writing-a-profiler-from-s...) and I'm looking forward to writing the next installment, in the next few days.

I write a blog post on this and related in-depth profiling topics every two weeks (you can follow me on social media https://twitter.com/parttimen3rd and https://mastodon.social/@parttimenerd to get notified).

_old_dude_2• 3 years ago

Hi.

I believe the code of the constructor of Profiler is not thread safe, it has a publication problem. The method onEnd can be called by the profiler thread while the fields options and store are not fully initialized.

From another thread POV, a final field is only fully initialized after the call to the constructor not inside the call to the constructor.

parttimenerd10• 3 years ago

Thanks. But this should only be a problem if the JVM terminates too fast, or am I wrong?

benmmurphy• 3 years ago

doesn't `Runtime.addShutdownHook` have a synchronisation point. like all writes need to have occurred before `ApplicationShutdownHooks.add` has been called so there is no publish problem.

          https://github.com/openjdk/jdk/blob/2fa09333ef0ac2dc1e44292f8d45d4571cb22cca/src/java.base/share/classes/java/lang/Runtime.java#L69
          https://github.com/openjdk/jdk/blob/2fa09333ef0ac2dc1e44292f8d45d4571cb22cca/src/java.base/share/classes/java/lang/ApplicationShutdownHooks.java#L65

maybe I'm missing something that is java specific with the way constructors work. I'm guessing even without the synchronisation point java lets you share objects in a way that would normally be considered unsafe as long as all the fields are final.

bitcharmer2• 3 years ago

Someone correct me if I'm wrong but this looks like another failed attempt at profiling Java code.

This approach forces a safepoint and therefore all results will be safepoint biased. That's a very good way to mislead oneself about where the cpu time goes.

The correct way is to employ asynchronous stack probing like async profiler or any other modern profiler does.

parttimenerd10• 3 years ago

(Author here) I want to quote from my article:

"Writing a Java profiler in 240 lines of pure Java is possible and the resulting profiler could even be used to analyze performance problems. This profiler is not designed to replace real profilers like async-profiler, but it demystifies the inner workings of simple profilers."

And you'll find a large disclaimer on top of the article explaining the safepoint-bias and linking to relevant blog posts by other people on this topic.

Please don't use this profiler in production, but you use it to further your knowledge of profilers.

The correct way is to employ asynchronous stack probing like async profiler or any other modern profiler does.

Guess what my other articles on my blog are about :) But as you'll see, using the asynchronous APIs is far harder and requires knowledge on POSIX signals, C programming and more that many Java developers do not have.

bitcharmer2• 3 years ago

Thanks for the clarification, I skimmed through the content faster than I should have. I stand corrected : - )

haglin• 3 years ago

An alternative to avoid safepoints (only samples executing threads)

    var r = new RecordingStream();
    r.enable("jdk.ExecutionSample").withStackTrace().withPeriod(Duration.ofMillis(1));
    r.onEvent("jdk.ExecutionSample", e -> {
        store.addSample(e.getStackTrace().getFrames());
    });   
    r.startAsync();
    ...

omazurov2• 3 years ago

You get JFR's precision but inherit its blind spots as described in [1]:

demo1: ... JFR will not report anything useful at all, since it cannot traverse stack traces when JVM is running System.arraycopy()

I'd rather run jstack in a loop than lose System.arraycopy() (or, in fact, any native code be it JVM's or JNI).

[1] https://github.com/apangin/java-profiling-presentation

parttimenerd10• 3 years ago

I would rather use Andrei Pangin's async-profiler than doing something custom with jstack.

Writing a Profiler in 240 lines of pure Java

Related Stories