I haven’t reflected on 2013 lately, and I know the reason why: every time I reflect about it, it seems more logical to provide the insight what would that mean for 2014. The experience tells us no matter how hard you plan, the plan is only good for a few months ahead. So, here’s the plan for my 2014.
Conceiving this "blog"
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:
the conferences I enjoy because of the crowd; it is enough to say the two conferences in 2014 like that were JVMLS and Joker
the conferences allowing you to preach complicated subjects to new people; this is either due to large turnaround in the audience, or generally large conference, which can also tolerate the hardcoreness of the talks I enjoy to deliver
I think the list of next gigs include:
Other than that, I want to contain the public exposure to this blog.
JDK 9: Java Memory Model
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
Java Concurrency Stress tests (jcstress)
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:
improving in test harness reliability, performance, and reporting capabilities
filling up the gaps in the ROADMAP
coming up with more high-level
figuring out more (generated?) tests for basic language features. Example: we do have enormous amount of test asserting the sequential consistency for volatile-only generated programs. Can we do better? Can we shrink the number of tests to just a few? Do we miss the blind spots?
JDK 8+: Lambdas and beyond
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
ForkJoinPool fronts. It is time to see what else we can do there.
JDK 8+: Point-wise performance research
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.
Java Microbenchmark Harness (JMH)
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:
@GenerateMicrobenchmarkannotations (this will let laymans' customization of benchmarks)
proper statistical inference in Java API (yay, Student T-tests, Welch-Shapiro normality testing, bootstrapping, and other madness Apache Commons Math bringing in)
always fork the VM even for the embedded runs (this will let e.g.
@CompilerControlto always work properly)
And here is the list of long-term things:
JOL profiler to measure
Want more? Drop the RFE (better yet, along with the implemented patch) to jmh-dev@
JDK 9: Microbenchmark Corpus
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.
Java Object Layout (JOL)
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.