Gesticulations and Other Geekery » Posts in 'JVM' category

Inlining and optimization of methods in the JVM

I was just reminded of something that I often forget. So I thought I’d mention it here.

When the JVM (at least Sun’s HotSpot) optimizes a method it will only create one optimized version. So that if more than one type of object is passed to the function it will prevent inlineing and other optimization. This means you have to be conscious of what you allow to be passed into methods that should be optimized since the compiler will optimize for the lowerest common denominator of all input values.

This is standard for JITs. However as a side note, there are JITs that do produce multiple optimized versions for functions that are used in more than one context. One example is Psyco. Work on Psyco has stopped and new development is going into PyPy which is a fascinating (and kind of deranged) project.

Posted in JVM

Inlining “objects” in the JVM

[EDIT: It has been pointed out that the correct term for what I am talking about is Scalar Replacement. Also it seems that Java 7 already has some code to support it in the JIT compiler. Thanks.]

One of the interesting features of Scala is the ability to use implicit conversions to “add” methods to existing classes. A call to “x.func” will try to convert x to a type with a method func if it doesn’t naturally have one. The problem is that each time this happens it ends up allocating a temporary wrapper object. This is similar to Java idioms like:

long time = new Date().getTime();

In both cases an object is allocated and then is immediately ready to be garbage collected. Whenever I think about this I feel that the JVM could optimize it away. Maybe something like this.

The JVM discovers (during escape analysis, which I think it already does) that the object is short lived and local. It then inlines the small number of method calls (often just one, especially in the case of scala implicit conversions). When it sees that every method call on the object is inlined it inlines the constructor and converts any fields of the class into local variable and removes the allocation entirely.

This wouldn’t be easy. But it doesn’t seem like it would be too incredibly hard. Though I’m not a JVM programmer so I don’t really know.

Maybe I should give it a shot. I’ve never hacked on Hotspot and I’ve always kinda wanted to.

Any thoughts on this?

Posted in Java, JVM, Scala