Koodihommia

A couple of podcasts I have listened to recently have flamed Java. It is a good "kusitolppa", a seriously uncool technology.  I'm pleased about not having to write Java anymore. Yet, I'll risk career suicide and take a stance to defend it against some of the low blows. After all, it was my bread and butter for quite many years. I get it; writing Java is not in fashion. It is likely a wrong choice for a modern startup. The language is full of mysterious cargo-cultish traditions, is verbose, has annotations on top of annotations and you have to use an editor which eats half of your memory (the other half is used by the Java process you are working on). Traditional Java and JDKs are ill-fitted for short-running processes like lambdas; it needs time to warm to get up to speed and needs more than one core to work efficiently. It has horrible dependency management tools by today's standards. Running a JVM process requires all kinds of weird flags, its defaults are unlik...

In an earlier blog post, I talked about flame graphs and how I implemented those for a Scala app. Ever since I have been thinking if it would be possible to grab a flame graph from a container. Some time ago I made that happen inspired by this post.  It was not enough for me, I wanted to go deeper. I wanted also the profiler to run inside a container profiling another container. So I ended up making this It uses the JVM  async-profiler tool so not quite the same that in my previous blog post but the results are similar. To profile another container, you can use the one-liner and replace the $CONTAINER_ID with the id of the running JVM container you want to profile, $PERF_IMAGE as the built image id of the described container and  $JAVA_PID with the, you guessed it, the JVM pid inside the subject container. You also need to set a couple of runtime variables on the docker host as described in the async-profiler setup instructions. There are a couple of drawbacks....