Michael Bebenita - Tracing JIT Notes

We're not just tracing Bytecodes, we're tracing the Web too. Today TraceMonkey is making a big splash, the super hackers over at Mozilla have landed the fastest Java Script VM ever!

It is based on our work on Tracing JITs, Andreas Gal's work on Trace Trees, my research on Nested Trace Trees, and Mason Chang's Type Speculative Tracing. It's great seeing your work turning out to be useful. Congratulations to the real heroes over at Mozilla for actually making it all work, great job!

Ok, so what's Maxine?

Lately we have been doing some work on compressing the amount of bailout code necessary to resume the state of the Interpreter in case of a bailout. So far we have identified three ways to deal with bailout code.

The visit at Adobe got me thinking about ways to reduce the code generated for trace bailouts. Currently we are seeing that 80% of the generated machine code is bailout code, this is what the Adobe folks are also experiencing in the Tamarin-Tracing project. Bailout code has a negative impact the code cache and on the assembler. The bailout code is very simple, it writes values from native code into the Interpreter's execution stack. At runtime these values may be either constants or in physical registers and virtual registers.

I just got back from visiting Adobe in Boston early this week. We had a very fruitful discussion with the Edwin Smith, Brendan Eich and Rick Reitmaier about tracing in Tamarin. We shared a lot of great ideas and I'm eager to start hacking on some of them. Andreas and I both gave talks on the stuff we've been working on. Here are the slides from my talk on Nested Trace Trees.

Object allocation can be done through JNI. However the AllocObject function will eventually fail once the heap is filled because a GC cannot be performed (this is because we lock the GC when executing native code). To prevent this scenario, which causes an irrecoverable failure in the Hotspot VM, we prematurely exit native code and switch back to the interpreter once the eden heap has filled beyond a certain threshold. Inside of the interpreter we can perform a System.gc() and then switch back to native code on the next iteration.

We made some progress on the AMD64 back-end. One of the problems we've been facing is creating an interface between Hotspot and our tracing JIT so that they can play nice together. Our first approach was to modify the Hotspot source code to provide a few extra features needed by our JIT. First, we needed a way to jump straight to an executable region of code, this is fairly easy to achieve using C function pointers. Second we needed to pass arguments to the executable region, and return them when the code exits.

A few days I stumbled over a problem in our AMD64 back-end. As any responsible grad student would do, I strayed off into an unexpected direction. I decided to write an AMD64 debugger for the code we generate. Mason mentioned that I use gdb and attach it to the running Hotspot process, find out where the code we generate is loaded and then step through it that way. While this is in theory possible, it’s quite messy, in my opinion at least. I wanted something nicer. So I figured I would write my own.

We’re in the process of packaging up the Hotpath source code so we can make it available for download. We are trying to remove dependencies on Hotspot so that the Hotpath VM will build and execute on all 64bit Hotspot platforms. I’d suspect that in a week or so we’ll have the code up for you to play with.

There was a slight bug we discovered while chatting with Chris Stork. Fields of hoisted allocation objects must be cleared out at the allocation site, or right before a guard instruction. For example: