Show HN: Javaflame – Simple Flamegraph for your Java application

Show HN: Javaflame – Simple Flamegraph for your Java application(github.com)

31 points by beothorn 2 years ago | 8 comments

Javaflame will generate a flamegraph of your application function calls, including the argument values and the return of each function.

Check https://beothorn.github.io/javaflame to see an example.

There are already some tools that render flamegraphs for java, but they are focused on measuring performance or require some other process running along with the application. They also record function calls, but do not record the arguments or return values from those functions.

I needed instead something to help understand and debug my applications that was better than adding breakpoints and slowly step over every call.

This is a simple java agent that renders a flamegraph on a html file, no extra dependencies or other processes involved. All you need is an extra argument passed to the JVM on the command line pointing to the java agent.

It calls toString on every parameter and return value of every function that is included on the filter, so I wouldn't use this outside your dev machine.

luzifer42 2 years ago |

Why reinvent the wheel? https://github.com/async-profiler/async-profiler#flame-graph...

Ok, Windows is not supported. But IntelliJ made a fork which works on Windows. https://packages.jetbrains.team/maven/p/ij/intellij-dependen...

beothorn 2 years ago | |

I took a better look. This, as other profilers, work by sampling the process, getting the stack trace all at once.

This is either getting it from tooling baked on the kernel (that is why it doesn't work on windows) or getting the stack sample from the JVM (see the tiny-profiler from part-time nerd above)

Sampling makes sense if you want to be as much non intrusive as possible. That is not how JavaFlame works.

What I do is injecting byte code on every function that matches the filters. This code will update a custom stack that stores not only the function name, but also uses reflection to get the argument and their values. In exit, it also records the return value.

It does record the time the function took to run, but this includes the time to get the values from the arguments. It is not exact, but it is good enough to get an idea of the overall logic.

In short, I don't think you can have the argument values with sampling.

beothorn 2 years ago | |

I did not know about this project, I will look into it, thanks for linking :)

But, from a quick peek, I think my motivation is different.

My intention when creating this was not profiling exactly each operation, but understanding the logic (what each function calls do and what parameters are passed). I see that this, apparently, does not capture argument values and return values (I may be wrong).

If you are profiling, that makes sense. Calling toString on every argument obviously affect the performance.

Another thing is that this is pretty simple, there are not many tweaks you need to do, as the goal is just to glance at the values being passed around at runtime.

If you look at the example page, with the sort algorithms, you will see that you can follow exactly how each one works by looking at the values being passed and returned. You don't get this from only looking at the calls.

parttimenerd 2 years ago |

I wrote a small profiler in ~240 lines of pure Java code: https://github.com/parttimenerd/tiny-profiler

It is reasonable fast :)

beothorn 2 years ago | |

Pretty cool!

renewiltord 2 years ago |

Interesting. Usually I use a flamegraph for performance reasoning. How do you use this flamegraph?

Cool tool btw.

beothorn 2 years ago | |

Mainly for debugging locally. I use it either to understand which parts of the code will be touched by a certain action or over unit tests to get an overall idea of what values are passed to which parts of the system.

Works well if you need to reproduce a bug and wants to check how did you get to whatever invalid state you are looking into. In contrast, before, I would do the same by adding a bunch of breakpoints and going through the function calls. This is slow, and specially annoying when you have lots of timeouts in your code.

But this is project is very new, I am starting to feel the actual json with the stacktrace is a little bit more useful than the graph itself to peek at the values. In the sort example, this would be https://www.isageek.com.br/javaflame/data.js

renewiltord 2 years ago | | |

Oh that's actually quite interesting. Yeah. I could see that be of use. I do the same.