AI Assistant for OpenJDK Contributors

2024-08-27 - By Marcus

Subtitle: ”Soon You’ll Know What I Did This Summer”

This summer my family and I decided to stay in Küssnacht during my summer vacation. The summers here are lovely, and for a family of six going for a vacation abroad it typically means a lot of time is spent preparing, packing and unpacking, for both directions of the journey. A staycation seemed like a good choice. Most days were spent in the water with the family, and on one occasion, we were joined by a team member and his family. It can get rather hot here, and the lake is the perfect place to cool down.

Me on a SUP overlooking part of my family on another SUP on Lake Lucerne

That said, I did end up in front of my computer a bit in the evenings after everyone else had fallen asleep. There were a few things I really wanted to get done this vacation. One was upgrading my server. Another one was to put some left over Raspberry Pi 4s and a few new Raspberry Pi 5s to good use in my 19” rack, creating my very own a little Kubernetes cluster.

Recently I was also playing with Custom GPTs, which is OpenAI’s way of letting you build little RAG (Retrieval Augmented Generation) systems without writing code. I first played a bit with Custom GPTs on a train ride back from the Datadog office in Paris a little while ago, and it was a quite lot of fun, but for some of the things I wanted it to do, it performed rather badly, and I couldn’t find any fitting APIs available to help my Custom GPT do better.

Since I was setting up a Kubernetes cluster anyway, I thought I might as well hack something together to make my OpenJDK Project Assistant a little bit better.

Setting Up the Cluster

Ah, the pain and the anguish. I ended up using my Apache server as a proxy (since I still want https://hirt.se to serve my old homepage and blog) for an Nginx that is acting as reverse proxy and load balancer to my Kubernetes cluster.

If anyone wants to know how I set up the cluster, that is an entirely different blog that probably already exists in a thousand versions, written by people with more patience to write about configuration than me, so I will not dwell on that. Suffice to say that I consulted many blogs and Claude 3.5 Sonnet to get it all up and running. Here are the steps in short:

Format and setup the Raspberries with Raspberry Pi OS (64-bit) (I used the Raspberry Pi Imager).
I added my Pis to the hosts file of my server and to my dhcpd config by MAC address, so that I can refer to the Pis by name instead of IP (I’m using dnsmasq).
I installed kubernetes on them, which involved properly enabling cgroups in /boot/firmware/cmdline.txt, setting up containerd properly, getting the debian package for k8s, installing kubelet, kubeadm, kubectl, turning off swap, and finally using kubeadm init to create the cluster and then applying flannel. Then using the join command you get from performing the init to have the other Pis join the cluster.

There was a bunch of trial and error, and there is probably a much easier way. Anyway, I now have a cluster. I can easily deploy. I can easily scale. What more could you ever wish for?

The API exposed to the CustomGPT is available to the world at https://api.hirt.se and described here, should anyone be interested. The implementation is available on GitHub – feel free to contribute if the custom GPT isn’t doing what you think it should be doing or if you simply want to make it more capable.

What Can the OpenJDK Project Assistant Do?

It can do lots of things. It can get information about open PRs and repos without overwhelming GPT with information that will invariably make it fail (this is what typically happened before the api.hirt.se API). For example, here’s getting the oldest open PR for the JDK project:

It can summarize the information in the PRs:

You can also ask for information about the related bug:

It can answer questions around people involved in OpenJDK:

For people like me, who have a really hard time remembering names, it can help answer questions about people involved in OpenJDK:

And about projects and groups:

Please let me know if you find it useful!

Summary

I recently had a stay-at-home vacation in Küssnacht.
Aside from spending a lot of the time in Lake Lucerne with my family, I did have some fun building a Kubernetes cluster out of my Raspberry Pis.
I put the cluster to good use to support my OpenJDK Project Assistant Custom GPT.
If you’re one of the few OpenJDK committers that also have access to Custom GPTs, or you simply like the idea, feel free to put a star on my API repo, or even better – contribute things you want it to be able to do, or do better!
Silly bonus: I also noticed that the silly old slogan image generator I was using on my homepage isn’t available under https (after my various upgrades, I now have permanent redirects to always use https). I couldn’t find any replacement that worked as a drop-in replacement, so I made my own variant that is now also running in my little cluster.

JDK Mission Control 9.0.0 Released!

2024-03-22 - By Marcus

The 9.0.0 GA release of JDK Mission Control was just tagged in the JMC repo at GitHub! Since this is the source release, it may still take a bit of time until the downstream vendors release binary builds of JDK Mission Control 9.0.0. I will try to remember to tweet or say something on the JMC Facebook page once the binaries start showing up.

Mission Control 9.0 – New and Noteworthy

General

JMC 9 – New Release!
This is the latest (2024) major release of JDK Mission Control. JMC 9 requires JDK 17+ to run and introduces several new features, enhancements, and bug fixes. This version continues to support connecting to, and parsing JFR recordings from, OpenJDK 8u272+ and Oracle JDK 7u40+, and can open and visualize flight recordings from JDK 7 and 8. JDK Mission Control is available for Windows (x86_64), Mac OS X (ARM and x86_64), and Linux (ARM and x86_64).

Eclipse 4.30 support
The Mission Control client is now built to run optimally on Eclipse 2023-12 and later. To install JDK Mission Control into Eclipse, go to the update site (Help | Install New Software…). The URL to the update site will be vendor specific, and some vendors will instead provide an archive with the update site.

Support for Linux/aarch64
JMC 9 is now built for Linux aarch64.

Support for dark mode
JMC 9 now supports dark mode. Go to Preferences, General | Appearance, and select the Dark theme to enable.

Minor bugfixes and improvements
There are 118 fixes and improvements in this release. Check out the JMC 9.0 Result Dashboard for more information.

Add user configuration for local JVM refresh interval
Previously the JVM Browser checked every 5000 ms for new JVMs. This can now be configured.

Core

Better JFR parser performance
Multiple efforts have been made to reduce allocations in the JMC parser, including: reduced allocation of Doubles, reduced allocation rate in ParserStats. Also, when duration events aren’t ordered by their end time (e.g. events which stack so that the last event finishes first, or file reads with overlaps) `DisjointBuilder.add` can be slow because of the linear search for the lane, and then a linear time reordering. This has been improved with a binary search.

Support checkpoint event sizes beyond u4 limit
The JMC JFR parser now support checkpoint event sizes beyond the u4 limit.

Move non-Eclipse dependent classes from org.openjdk.jmc.ui.common to org.openjdk.jmc.common
There were a number of classes previously in jmc.ui.common that would be a great asset to the core distribution (and the third-party applications that consume jmc-core), and these classes now live in jmc.common. Please see JMC-7308 for further information.

Move rjmx bundle from application to core
The rjmx classes and related services (FlightRecorderService) are now exposed for third-party application usage. Please see JMC-7069 for further information.

Move org.openjdk.jmc.flightrecorder.configuration bundle from application to core
The org.openjdk.jmc.flightrecorder.configuration bundle contains many classes useful for working with jfr, and are now available in core. Please see JMC-7307 for further information.

Java Flight Recorder (JFR)

The Event Browser now supports searching and showing event type ids
Searching in the search bar now also searches event type IDs, and there is also a (by default hidden) column that makes it easy to show the event type IDs for the shown events.

Add support for enabling jfr on native images
Previously JMC was unable to start flightrecorder on a graalvm native image, even if there is built-in jfr support. This has now been fixed.

Java based flamegraph visualization
The previous flamegraph visualization takes place in an embedded browser component (provided by the Eclipse platform), unfortunately this approach has some drawbacks, the first being a bit slow. This view is now using a Java (Swing) based flamegraph library. Also, the flame graph model creation performance have been improved.

Visualization and Rule for FileChannel.force()
The File I/O page has been updated to show force related information. There are two new columns added – Force Count and Update Metadata. Both are hidden by default and can be enabled by right clicking the table. The chart will also include a File Force row. There is a preference setting for the associated file force rule, where the peak duration warning limit can be set. See JMC PR#533 for more information.

Rule that checks on G1 pause time target compliance
New rule that looks at the pause time target and compares it to the actual pauses.

Rule that looks at finalization statistics
JDK 18 comes with a FinalizationStatistics event that helps users find where in their application finalizers are run. This is important as finalization has been deprecated for removal in a future release. For more information about finalization and its flaws, see https://openjdk.java.net/jeps/421. Even if an application doesn’t implement any finalize() methods, it may rely on third-party libraries that does. Static analysis of third-party libraries using “jdeprscan –for-removal” can be used to list those classes, but it will not tell if they are being used. For example, an application may be missing a call to a close() method, so the resource is cleaned up by the finalizer, which is sub-optimal.

Rule that detects GC Inverted Parallelism
Rule inspired by the “Inverted Parallelism” analysis in Garbagecat. See JMC-8144 for more information.

Support for the new JPLIS agent events
There is now a new page and rule for loaded JPLIS agents. See JMC-8054 for more information.

Twitter plug-in removed
Due to changes in APIs and cost of maintenance, the Twitter plug-in has been removed.

Bug Fixes

Area: Agent
Issue: 8045
Synopsis: retransformClasses() doesn’t re-transform all needed classes

The retransformClasses() methods in Agent and AgentController use Class.forName() to try to get the class objects of classes needed to re-transform. This obviously doesn’t work for classes loaded by classloaders different from the one which loads the agent. Those classes would be instrumented if they were loaded after their event probes were defined the AgentController. But when loaded earlier they would not be instrumented. This has been fixed.

Area: Agent
Issue: 8048
Synopsis: Agent throws exceptions on missing or empty descriptions

When the description of an event or value is empty or missing, the agent fails with exceptions. This has now been fixed.

Area: Console
Issue: 8154
Synopsis: Some JMX attributes are missing unit specifications in the Console

The missing unit specifications have now been added.

Area: Core
Issue: 8063
Synopsis: IMCFrame Type cache not synchronized

The type cache used in the IMCFrame Type inner class wasn’t synchronized and could cause a concurrent modification exception during e.g. JFR parsing. This has been fixed.

Area: Core
Issue: 8156
Synopsis: JfrRulesReport.printReport does not respect verbosity for text and json

The verbosity flag for text and json reports didn’t work. This has been fixed.

Area: Core
Issue: 8041
Synopsis: JfrRulesReport json reports produce incomplete results

While generating JFR Rules Reports in json format, the results were incomplete. The components “message” and “detailedMessage” were not populated. This has been fixed.

Area: JFR
Issue: 7885
Synopsis: Graphical rendering of dependency view fails due to heap memory drain

Also JMC-7496. The dependency view drains the heap memory and causes out-of-memory exceptions and performance delays. This has been improved.

Known Issues

Area: JFR
Issue: 7071
Synopsis: JMC can’t attach to jlinked JVMs

This one is still under investigation, but it seems JMC can’t attach to certain jlinked images.

Area: JFR
Issue: 7003
Synopsis: The graph view, heatmap view and dependency view does not work on Windows

This is due to a problem with the Windows based browser component in SWT. We’re hoping for a fix in the component for a future version of the Eclipse platform.

Fantastic JVMs and Where to Find Them

2020-07-20 - By Marcus

Since you’re reading this blog, chances are that you’re writing software which will eventually run on a JVM. Most of you are using the Java language. Many of you are using a variety of other languages that target the JVM, such as Scala, Kotlin, Clojure, Groovy, (J)Ruby etc. Eventually you’ll need to decide on which JDK/JRE to deploy your software on in production. This is much easier said than done. There are quite a few different vendors out there, providing support and taking responsibility for the binaries they produce. They can have different support lengths for specific versions, and whereas you can sometimes find a vendor providing extended support for a version that has been officially end-of-lifed at Oracle, you may not find builds with the latest fixes in them publicly available. You’ll need to get those directly from the vendor.

After trying to figure out what’s what, I thought I’d simply write a blog post on the various JDKs available out there. This is especially important, since you might be consuming your JDK from a container provided by a third party, e.g. Docker Hub, and you may not know exactly what you’re getting[1].

Release Version Chicken Race

Typically most companies will require that you keep your dependencies up-to-date. For example, if you’ve written something with a dependency on Tomcat, you are pretty likely to keep your dependencies up-to-date. GitHub may even warn you if you’re running with a version that has known security implications. However, not everyone is keeping their JDKs/JVMs up-to-date. Which is funny, in a way, since everything you’ll be running could be affected.

Let’s take the Oracle JDK as an example. JDK 7 was GA in July 2011. Publicly available updates and fixes ceased in April 2015. Oracle’s Premier Support ended in July 2019, and even the Extended Support ends 2022.

Let’s say you’re running on JDK 7. If you got your JDKs from Oracle, without a support contract chances are that the latest version of JDK 7 you got was built in 2015. You are now five (5!) years behind on critical security patches.

In other words, if you’re still running your software on JDK 7, you may want to at least begin upgrading to 8. JDK 7 is dying and support is being dropped left and right. If you aren’t buying support and have someone provide you with (security) patches, you might want to accelerate the effort. Also, this particular upgrade (7->8) should be relatively painless – in most cases it will be a drop in replacement. Now, if you’re not running a JDK 7 with the latest patches (sanity check – was the JDK at least built this year?), you may not only be missing out on bug fixes, but you may also be missing out on security patches[2]!

The same arguments could be made for JDK 8 as well, on a slightly pushed out time-line. The good news is that there are still public (and free) updates coming from the OpenJDK 8 maintenance project. That said, there are plenty of advantages for upgrading to JDK 11+, better performance being one of them.

Now, when the new, faster, release schedule was announced, Oracle announced that every 3 years, there would be an LTS (Long Term Support) version of Java. The releases in between the LTS releases would only be supported until the next release came out. Most vendors have adopted the same support scheme, which means that, at the time of writing, you should not be running ANYTHING on JDK 9,10,12 and 13 (unless you’re using Azul distributions, see [3]). They are not supported. Running them will only mean that you are lacking bug- and security fixes. To take a somewhat arbitrary example – if you stopped upgrading JDK 8 after 8u74, you are literally lacking thousands of fixes.

At the time of writing this blog, the new CPU (Critical Patch Update) releases have just been published, and these are the releases you should be running in July 2020 (sooner rather than later):

JDK 8u262
JDK 11.0.8
JDK 13.0.4 [3]
JDK 14.0.2

If you’re running anything else in production, without a support contract, it could be argued you’re not doing things quite right.

What’s what?

OpenJDK, being open sourced, has builds provided by plenty of vendors. Here is a non-exhaustive list of some vendors shipping supported versions of OpenJDK (in alphabetical order, distribution(s) in parenthesis):

AdoptOpenJDK
Alibaba (Dragonwell)
Amazon (Corretto)
Azul (Zulu, Zing)
BellSoft (Liberica)
Red Hat (Red Hat Builds of OpenJDK)
Oracle (Oracle JDK, Oracle OpenJDK)
SAP (SapMachine)

These providers usually ship distributions with pretty much the same bits from the OpenJDK repository, sometimes differing by what features are enabled, for example like a GC (Shenandoah / Red Hat), or by adding proprietary features like a new compiler (Falcon / Azul (Zing)). Some vendors have a free distribution (e.g. Oracle OpenJDK, Azul Zulu) and one that requires a commercial license (Oracle JDK, Azul Zing). Which vendor and distribution you should select depends on your demands – e.g. which vendor can provide reliable support to you (Oracle is one of the biggest contributors to OpenJDK), or which one provides the feature you need at a price point you can afford (e.g. JDK Flight Recorder on JDK 8 without the need for a commercial license, or support for a specific GC or compiler).

There are also upstream builds, not supported by anyone, built on Red Hat infrastructure and hosted by AdoptOpenJDK. For example, if you get a JDK 8 from Docker Hub (openjdk/jdk8u252, openjdk/jdk8), that is what you would get.

Where to get JFR – Public Service Announcement

As you probably know, JDK Flight Recorder, a technology close to my heart, has been backported to JDK 8. Since we’re talking about where to get your JVMs and versions, I thought I’d include a small table for which provider will be including JFR in what version of their JDK 8 builds.

Vendor	First JDK 8 Version with JFR	Release Date	Docker Image
Azul (Zulu)	u212* (u262+ recommended)	2019-04-16	azul/zulu-openjdk/8
AdoptOpenJDK	u262	2020-07-16	adoptopenjdk/8u262
Red Hat	u262	2020-07-15	In Fedora and RHEL
Amazon (Corretto)	u262	2020-07-14	amazoncorretto:8u262
Bell-Soft (Liberica)	u262 (separate binary)	2020-07-14	N/A
Upstream builds [4]	u272	2020-10-20	openjdk/jdk8u272, openjdk/jdk8

Summary

Use the latest version of an LTS which is still supported, or the latest version
Use a supported build in production (even if you haven’t bought support)

Thanks to Mario Torre, JP Bempel and Gil Tene for feedback!

[1]: Mystery meat OpenJDK builds strike again: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009330.html

[2]: To check the vulnerabilities you may be exposed to, see e.g. https://www.cvedetails.com/version-list/93/19116/1/Oracle-JDK.html?sha=b856721542b66953c859bd95be067255dd4c6098&order=1&trc=188

[3]: Upstream JDK 13u is being supported, and Azul has announced 13 to be “Medium Term“ supported – you can keep getting updates for JDK 13 for Azul distributions.

[4]: These are built by Red Hat and hosted by AdoptOpenJDK, and are different from Red Hat’s and AdoptOpenJDK’s supported builds.

Fetching and Building Mission Control 8+

2019-11-25 - By Marcus

As described in a previous post, Mission Control is now on GitHub. Since this alters how to fetch and build OpenJDK Mission Control, this is an updated version of my old post on how to fetch and build JMC from version 8 and up.

Getting Git

First step is to get Git, the SCM used for OpenJDK Mission Control. Installing Git is different for different platforms, but here is a link to how to get started:

https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

Installing the Skara Tooling (Optional)

This is an optional step, making it easier if you want to contribute to Mission Control:

https://hirt.se/blog/?p=1186

Cloning the Source

Once Git is installed properly, getting the source is as easy as cloning the jmc repo. First change into the directory where you want to check out jmc. Then run:

git clone https://github.com/openjdk/jmc.git

Getting Maven

Since you probably have some Java experience, you probably already have Maven installed on your system. If you do not, you now need to install it. Simply follow the instructions here:

https://maven.apache.org/install.html

Building Mission Control

First we need to ensure that Java 8 is on our path. Some of the build components still use JDK 8, so this is important.

java –version

This will show the Java version in use. If this is not a Java 8 JDK, change your path. Once done, we are now ready to build Mission Control. Open up two terminals. Yep, two!

In the first one, go to where your cloned JMC resides and type in and execute the following commands (for Windows, replace the dash (/) with a backslash (\)):

cd releng/third-party
mvn p2:site
mvn jetty:run

Now, leave that terminal open with the jetty running. Do not touch.

In the second terminal, go to your cloned jmc directory. First we will need to build and install the core libraries:

cd core
mvn install

Next run maven in the jmc root:

mvn clean package

JMC should now be building. The first time you build Maven will download all of the third party dependencies. This will take some time. Subsequent builds will be less painful. On my system, the first build took 6:01 min. The subsequent clean package build took 2:38.

Running Mission Control

To start your recently built Mission Control, run:

Windows

target\products\org.openjdk.jmc\win32\win32\x86_64\jmc.exe -vm %JAVA_HOME%\bin

Mac OS X

target/products/org.openjdk.jmc/macosx/cocoa/x86_64/JDK\ Mission\ Control.app/Contents/MacOS/jmc -vm $JAVA_HOME/bin

Contributing to JDK Mission Control

To contribute to JDK Mission Control, you need to have signed an Oracle Contributor Agreement. More information can be found here:

http://openjdk.java.net/contribute/

Don’t forget to join the dev list:

http://mail.openjdk.java.net/mailman/listinfo/jmc-dev

We also have a Slack (for contributors), which you can join here:

https://join.slack.com/t/jdkmissioncontrol/signup

More Info

For more information on how to run tests, use APIs etc, there is a README.md file in the root of the repo. Let me know in the comments section if there is something you think I should add to this blog post and/or the README!

Using the Skara Tooling

2019-11-15 - By Marcus

I’m writing this for myself as much as I’m writing this to share. After only a day of using JMC with Skara, I’ve fallen in love with it. I spend less time painstakingly putting together review e-mails, copying and pasting code to comment on certain lines of code, cloning separate repos to do parallel work efficiently, setting up new workspaces for the these repos etc. Props to the Skara team for saving me time by cutting out a big chunk of the stuff not related to coding and a whole lot of ceremony.

Note that the Skara tooling can be used outside of the scope of OpenJDK – git sync alone is a good reason for why everyone who wants to reduce ceremony can benefit from the Skara tooling.

So, here are a few tips on how to get started:

Clone Skara:
git clone https://github.com/openjdk/skara
Build it:
gradlew (win) or sh gradlew (mac/linux)
Install it:
git config --global include.path "%CD%/skara.gitconfig" (win) or git config --global include.path "$PWD/skara.gitconfig" (mac/linux)
Set where to sync your forks from:
git config --global sync.from upstream

For folks on Red Hat distros, 2 and 3 can be replaced by make install. For more information on the installation, see the Skara wiki.

Some Examples

To sync your fork with upstream and pull the changes:
git sync --pull

Note: if the sync fails with the error message “No remote provided to fetch from, please set the –from flag”, remember to set the remote for your repo, e.g.
git remote add upstream https://github.com/openjdk/jmc

To list the open PRs:
git pr list

To create a PR:
git pr create

To push your committed changes in your branch to your fork, creating the remote branch:
git publish

JMC Workflow

Below is the typical work-flow for JMC.

First ensure that you have a fork of JMC. Either fork it on github.com, or on the command line:
git fork https://github.com/openjdk/jmc jmc

You typically just create that one fork and stick with it.

(Optional) Sync up your fork with upstream:
git sync --pull
Create a branch to work on, with a name you pick, typically related to the work you plan on doing:
git checkout –b <branchname>
Make your changes / fix your bug / add amazing stuff
(Optional) Run jcheck locally:
git jcheck local
Push your changes to the new branch on your fork:
git publish (which is pretty much git push --set-upstream origin <branchname>)
Create the PR, either on GitHub, or from the command line:
git pr create

Summary / TL;DR

I ❤️ Skara

Mission Control is Now Officially on GitHub!

2019-11-14 - By Marcus

Since this morning, the JDK Mission Control (JMC) project has gone full Skara! This means that the next version (JMC 8.0) will be developed over at GitHub.

To contribute to JDK Mission Control, you (or the company you work for) need to have signed an OCA, like for any other OpenJDK-project. If you already have an OpenJDK username, you can associate your GitHub account with it.

Just after we open sourced JMC, I created a temporary mirror on GitHub to experiment with working with JMC at GitHub. That mirror is now closed for business. Please use the official OpenJDK one from now on:

https://github.com/openjdk/jmc

If you forked or stared the old repo, please feel free to fork and/or star the new one!

Compressing Flight Recordings

2019-11-09 - By Marcus

Flight recordings are nifty binary recordings of what is going on in the runtime and the application running on it. A flight recording contains a wide variety of information, such as various kinds of profiling information, threat stall information and a whole host of other information. All adhering to a common event model and with the ability to dynamically add new event types.

In the versions of JFR since JDK 9, some care was taken to reduce the memory footprint by LEB 128 encoding integers, noting that many things, like constant pool indices, usually occupy relatively low numbers. The memory footprint was cut in about half, compared to previous versions of JFR.

Now, sometimes you may want to compress the JFR data even further. The question then is – how much can you save if you compress the recordings further, and what algorithms would be best suited for doing the compression? What if you want the compression activity to use as little CPU as possible?

My friend and colleague at Datadog, Jaroslav Bachorik, set out to answer that question for some typical recording shapes that we see at Datadog, using a set of compression algorithms from Apache Commons Compress (bzip2, LZMA, LZ4), the built in GZip, a dedicated LZ4 library, XZ, and Snappy.

Below is a table of his findings for “small” (~1.5 MiB) and “large” (~5 MiB) recordings from one of our services. The benchmark was run on a MacBook Pro 2019. Now, you’d have to test on your own recordings to truly know, but I suspect that these results will hold up pretty well with other kinds of loads as well.

Algorithm	Recording Size	Throughput	Compression Ratio	Utility
Gzip	small	24.299	3.28	79.647
Gzip	large	5.762	3.54	20.436
BZip2	small	6.616	3.51	23.198
BZip2	large	1.518	3.84	5.826
LZ4	small	133.115	2.40	319.394
LZ4	large	38.901	2.57	100.009
LZ4 (Apache)	small	0.055	2.74	0.152
LZ4 (Apache)	large	0.013	3.00	0.039
LZMA	small	1.828	4.31	7.882
LZMA	large	0.351	4.37	1.533
Snappy	small	134.598	2.27	305.494
Snappy	large	35.986	2.49	89.692
XZ	small	1.847	4.31	7.964
XZ	large	0.349	4.37	1.523

Throughput is recordings/s. Utility is throughput * compression ratio, and meant to capture the combination of compression strength and performance. Note that the numbers are not normalized – only compare numbers in the same size category.

Summary / TL;DR

The built-in GZip is doing a fairly good/balanced job of compressing flight recordings
You can get the best utility out of LZ4, closely followed by Snappy, but you sacrifice some compression
If you’re prepared to pay for it, LZMA and XZ give a good compression ratio
All credz to Jaroslav for his JMH-benchmark and all the data

JFR is Coming to OpenJDK 8!

2019-11-06 - By Marcus

I recently realized that this isn’t common knowledge, so I thought I’d take the opportunity to talk about the JDK Flight Recorder coming to OpenJDK 8! The backport is a collaboration between Red Hat, Alibaba, Azul and Datadog. These are exciting times for production time profiling nerds like me. Smile

The repository for the backport is available here:

http://hg.openjdk.java.net/jdk8u/jdk8u-jfr-incubator/

The proposed CSR is available here:

https://bugs.openjdk.java.net/browse/JDK-8230764

The backport is keeping the same interfaces and pretty much the same implementation as is available in OpenJDK 11, and is fully compatible. There were a few security fixes, due to there not being any module system to rely upon for isolation of the internals, also, some events will not be available (e.g. the Module related events) but other than that the API and tools work exactly the same.

JDK Mission Control will, of course, be updated to work flawlessly with the OpenJDK 8 version of JFR as well. The changes will be minute and are only necessary since Mission Control has some built-in assumptions that no longer hold true.

You can already build and try out OpenJDK 8 with JFR simply by building the JDK available in the repository mentioned above. Also, Aleksey Shipilev provide binaries – see here for details.

Have fun! Smile

Flight Recorder & Mission Control at Code One 2019

2019-08-27 - By Marcus

Code One is rapidly approaching (September 16-19). For fans of JDK Flight Recorder and JDK Mission Control, there will be a lot of relevant activities at Code One. This is an attempt to list them. If I missed something, please let me know!

Sessions

Here are the regular sessions:

Session Name	Presenters	Day	Time	Location
JDK Mission Control: Where We Are, Where We Are Going [DEV4284]	David Buck	Monday	9:00	Moscone South Room 301
Introduction to JDK Mission Control and JDK Flight Recorder [DEV2316]	Marcus Hirt Klara Ward	Monday	16:00	Moscone South Room 202
Improving Observability in Your Application with JFR and JMC [DEV3460]	Marcus Hirt Mario Torre	Tuesday	11:30	Moscone South Room 201
Java Flight Recorder: Black Box of Java Applications[DEV3957]	Poonam Parhar	Wednesday	12:30	Moscone South Room 203
Robotics on JDK 11? With Modules? Are You… [DEV2329]	Marcus Hirt Miro Wengner Robert Savage	Wednesday	16:00	Moscone South Room 313
Four Productive Ways to Use Open Source JFR and JMC Revisited [DEV3118]	Sven Reimers Martin Klähn	Thursday	11:15	Moscone South Room 304
Enhanced Java Flight Recorder at Alibaba [DEV3667]	Sanhong Li Fangxi Yin Guangyu Zhu	Thursday	12:15	Moscone South Room 203
Performance Monitoring with Java Flight Recorder on OpenJDK [DEV2406]	Hirofumi Iwasaki Hiroaki Nakada	Thursday	13:15	Moscone South Room 201

Again, if I’ve missed one, please let me know!

Other Activities

There is going to be a hackergarten session around JMC and JFR, Wednesday at 14:30-16:00, inside of the Groundbreakers booth in the Exhibition Area.
On Friday a few JMC project members are planning to meet up for some coding between 10:00 and 12:00, and then have lunch together at 12:00. Ping me (Marcus) for an invite.
On Wednesday at 18:00 a few JMC project members are planning to go for dinner. Ping me (Marcus) for an invite.

Summary

Lots to do at Code One 2019 for fans of JFR and JMC.
Helpful links above.

Using Dynamic Working Sets in Eclipse

2019-01-29 - By Marcus

JDK Mission Control is quite modular. To help navigate the source, working sets come in quite handy. And for a more flexible way to define working sets, Oomph provide a very nice plug-in for constructing dynamic working sets, using rules and regular expressions.

To use, first install the Oomph Dynamic Working Sets plug-in into your Eclipse:
https://wiki.eclipse.org/Dynamic_Working_Sets#Download.2FInstallation

Next either start creating your own working sets, or start out with the ones I use:
https://github.com/thegreystone/jmc-dev-helpers

To edit/create the working sets, go to Preferences | Oomph / Dynamic Working Sets, and press Edit…

Once satisfied with the working sets, you can switch the Package Explorer to using the Working Sets as Top Level Elements:

Good luck!