JavaOne => J1 | Nutter on JVM | Groovy Beta Bytecode Diet

by Tim O'Brien

If you are following JavaOne on Twitter, you should "track javaone". If you haven't already signed up, you should read Bob Lee's Going to JavaOne? Sign up for Twitter blog entry from two days ago. People were using Twitter last year a bit, but this year is the year Twitter is going to change the JavaOne experience for attendees that are using it. In fact, it looks like Charles Nutter has already changed the name of JavaOne on twitter:


headius.png


Not only is that easier to type and write, but it's the new name we've all been looking for. He goes on to write a piece about how Groovy and JRuby attained massive performance improvements...

Nutter On How the JVM was made for Dynamic Languages, and how it only gets better in the future...

Charles' post from yesterday is getting loads of attention, it was #5 on Reddit homepage this morning... The Power of the JVM.


... JRuby's performance regularly exceeded Groovy's, even though several Ruby features require us, for example, to allocate a synthetic call frame for *every* Ruby method invocation and most block invocations. And JRuby had only received serious work for about 1.5 years. The problem was not that Groovy was an inherently slow language...the problem was the huge amount of code that calls had to pass through to reach their target...


He talks of the recent 2x to 5x speed improvement in Groovy in the context of call path optimization in JRuby. He references Guillaume Laforge's Groovy 1.6-beta-1 release announcement.

Nutter goes on to talk about how the JVM is best suited for Dynamic languages because it has a JIT and a VM that is always watching for optimizations (he points out that the most important part is that it can deoptimize). Another quote from Nutter:


...The JVM's ability to deoptimize and return to interpretation gives it room to be optimistic...room to make ambitious guesses and gracefully fall back to a safe state, to try again later.


He continues to paint a picture of a bright future thanks to John Rose's work on JSR-292 "invokedynamic". In a related note, if you are interested in Nutter's post, you'll be interested in John Rose's blog post n Method Handles, here's a great ending that relates to Nutter's post:


But the point is not calling or using these things from Java; the point is using them, down near the metal, to assemble the next 700 witty and winsome programming languages.


Groovy's Been on a Bytecode Diet

This is the weekend before J1, so everyone tends to make releases. Groovy, releases 1.6-beta-1. Looks like they focused on performance over features. Read Laforge's announcement he talks of the performance improvements, multiple assignments, and AST transformations.


Beyond delivering stable and quality releases, our main focus over the past 10 months has clearly been on performance.
Between Groovy 1.0 and 1.5.1, on these same tests, we had already gained up to 80% speed improvements, and even between "dot releases" (1.5.1 and 1.5.6) we gained again up to 40% more. However, it's really in the development branch that we've integrated advanced call site caching techniques and bytecode diets in the runtime to get the 150-460% speed improvements mentioned above.