Third time lucky?

In JamVM 1.5.0 I released the "inlining interpreter" which copies code blocks together in a similar way to a simple JIT (but the code is compiled by gcc, rather than being generated natively as in a JIT). This achieved an impressive speed improvement and I've been keen to optimise it further.

The major thing which has been in my sights is the remaining dispatches between adjacent basic blocks. For instance the fallthrough edge of an "if" and across the edge caused by a jump target.

Currently, the unit of inlining is a basic block because this has only one entry point and one exit point. Blocks which contain instructions which need to be rewritten (quickening, e.g. after symbolic resolution) must be executed first using threaded dispatch. If we inlined across blocks we will end up with blocks with multiple entry and multiple exit points. In this case, depending on control flow, we may complete the block before all the block has been executed, or we may never reach the end of the block because a side exit is always taken. In the first case, inlining can't be done, and in the second inlining will never occur.

My first approach to solve this was simplistic, and was more of an experiment to "test the water". So I wasn't too surprised when it didn't yield any speed improvement.

My second attempt was much more complex (after inlining check the edges and create a longer block if the blocks across the edge are both inlined, and fix up internal targets). But this showed no significant general speed improvement (order of 2%) although specific microbenchmarks showed over 100%.

So for the last week I've been trying to explain the results. After some experiments I've come to the conclusion that it is due to instruction cache locality. Basically, the merged block (which may be merged many times) ends up in a different location to the non-mergeable blocks which remain in the initial position. Previously, inlining exhibited good cache locality due to blocks being allocated in execution order. This was destroyed by block merging. The effects of this counteracted the speed improvements leading to no change overall.

This was the position I was in on Friday (which added to my despondency). However, on the weekend I rethought the problem and came up with a third approach. I've partially implemented it and hopefully should be able to test it in a few days. Fingers crossed!

JamVM : back on the map

I feel like a kid who's thrown a tantrum and been rewarded with an ice-cream. In my last post I really thought I was asking a "serious and legitimate question" but it's difficult not to squirm when you get the praise you were secretly hoping for...

So I'm grateful to all those who replied. JamVM is firmly back on the map :)

JamVM : road to nowhere?

Change logs and development notes never give any insight into the wider whys and wherefores of a project. Perhaps that's for the better; stick to the facts, that's what engineers are good at. But as this is my first real post on JamVM (now that I know everything is working) I think it's appropriate.

I started JamVM because I stopped being paid to work on proprietary VMs (after leaving a suitable gap). Because of worries of tainting I started my own VM rather than helping out on another. For the same reason I never directly contributed to GNU Classpath either. Of course, I wanted to make it smaller than any other, and I also wanted to make it open-source.

I work on JamVM because I enjoy it. It's also nice to get the (occasional) positive email from users, and to see people using it on a whole variety of hardware. The download statistics are also still going up (last month downloads from sourceforge was over 1000 for the first time, and this doesn't include all the distros that package it and embedded buildroots).

The problem is I sometimes wonder whether I'm flogging a dead horse and I'd be better off contributing my time to something else. I'm not trying to throw my toys out of the pram either; this is a serious and legitimate question.

Of course, the reason is OpenJDK and to a lesser extent PhoneME. Java is now open-sourced, mostly unencumbered and finally packaged. At best am I wasting my time, and at worst am I fragmenting and confusing things? Opinions, dear readers, gratefully received.

I discussed this with Jeroen Frijters at FOSDEM. In danger of misrepresenting things due to alcohol abuse, the general upshot was "why care?". If you still enjoy doing it, then do it. So I am.

First Post!

With the orbits of the Java planets colliding I've decided it's about time that JamVM got a blog! It's only taken 5 years :)