2014 Plans

After some careful thinking, I now need to have something more solid than assorted blogs here and there. Also, something that accepts more than 140 symbols for solidifying the ideas. I was accustomized to use Russian for most of my Internet ramblings, but the audience there seems too shallow for the topics I bring in.

That puts me in the weird position where I have plenty of excellent technical things written out in Russian without the opportunity to link them freely within the discussions I usually have in English.

After some twiddling with static blog generators, I can safely assume to hate them all. Hence, the "blog" here would be just plainly generated from asciidoc with the help of Asciidoctor. The script generating the list of all available blog posts and the RSS feed will follow soon.

In 2013, the realisation kicked in that I don’t like "developer" conferences, because those conferences are really about the non-fundamental things boosting no interest in me. God forbid me wasting time at another conference preaching HTML5 vs. AngularJS flamewars or something like that. In 2014, I plan to attend only two types of conferences:

I think the list of next gigs include:

Other than that, I want to contain the public exposure to this blog.

With the underground work to overhaul the JMM is gearing up, this might consume the substantial amount of my time in 2014. Most of the changes in model (suprise!) affect performance on different platforms, and so we would need to chime in about that early. Stay tuned for public announcements, conceiving the expert group, and hot discussions on what needs to be fixed, and what are the costs of fixing things.

Example: should we widen the initialization safety for the fields written in constructor beoynd final fields?

In the wake of JMM work, concurrency testing for Java platform gets increasingly more interesting. While there are tests which are arguably good in testing the basic things in the platform, more targeted tests are required to cover up the testing holes.

That means more jcstress development work. This is where we could actually use lots of help. There are lots of fun and tedious work items to do, including, but not limited to:

Now that the development work for Lambdas is gearing down, and the implementation is actually stable, we can dig into the performance improvements there (remember the "First make it right, then make it fast" motto). We did a lot in background during the development, especially on LambdaMetaFactory and ForkJoinPool fronts. It is time to see what else we can do there.

It would be dumb to assert one-off things would not happen. I do enjoy answering (silly) questions on StackOverflow, because it feels like constraining the stupidity before it starts to be googlable. Some of my Russian posts also include quite a few largish introspects into the platform performance, not matter how short the shelf life of those introspects is.

If you have a misconception crying to be busted, drop me a line.

We have the ultimate responsibility over the performance of Java platform, and part of that responsibility is providing people with the right tools to make the performance improvements of their own. This requires us to continue to maintain the Java Microbenchmark Harness.

This tool, among other things, requires the contingency plan. That is, there should be quite a few persons who can take over the development in the hypothetical case Acme Anvil suddenly meets me somewhere along 2014. Open for volunteers! There are lots of things to clean up, quite a few things to redo, a number of things to extend JMH with. Please go ahead and contribute!

Enough with usual contributor sadness, here is the list of things in the works:

And here is the list of long-term things:

Want more? Drop the RFE (better yet, along with the implemented patch) to jmh-dev@

This idea keeps running in the back of my head for several years now. The way we quantify performance for the large platform is essentially geared down to a few benchmark suites, like SPECjvm2008, or the largish customer workloads. While it quantifies the pervasive changes in the platform performance quite reliably, more intricate changes require (now hold your breath) microbenchmarking.

Now that we have the place for functional tests in OpenJDK, it seems fitting to ramp up the similar corpus of (regression) microbenchmarks. Opening up JMH and publishing it in Maven Central was the step forward to that goal.

Also, we do have lots of microbenchmarks already for different aspects of JDK performance. Having the corpus will hopefully increase our performance testing coverage, down to concrete user examples and regression tests.

Infamous java-object-layout now lives in OpenJDK, now called capitalized Java Object Layout (jol). This is actually one of the self-contained things which I can declare stable, and only requiring the maintenance work.

Nevertheless, I think it needs some more exposure, especially in the west hemisphere. There is a lone Russian talk about its capabilities that I did late 2013, and I should really go out on this…​ I do expect people to find more interesting and intriguing things to do with this kind of introspection available.