Rooftop lab

The ActionMonkey team, in no sensible order. Names in parentheses are IRC nicknames.

Brendan Eich (brendan) - Mozilla’s superstar CTO. Invented JavaScript; wrote SpiderMonkey; still very active in its development.

Jason Orendorff (jorendorff) - Your humble author. I’m here to do ActionMonkey grunt work.

Edward Lee (Mardak) - Mozilla summer intern working on MMgc integration. Mardak’s here to do the grunt work that I’m too dumb to handle.

You - I’m just saying. You could start pulling your weight around here. If you were so inclined. (Seriously: if you’re at all interested in hearing more, please comment on this post.)

There are many more people involved in this story: more Mozilla hackers with deep SpiderMonkey and XPConnect knowedge; the wonderful people at Adobe who donated Tamarin and are dedicated to continuing work on it in the open; the ECMAScript 4 committee, which is doing some other work that will soon collide with ActionMonkey’s world; and people from academia interested in fiendishly clever JIT techniques, security gadgets, and more. I’m sure I’ll write more about them all soon, but this will have to do for now.

I mentioned there are some challenges ahead. We need to integrate Tamarin’s garbage collector, MMgc, into Mozilla. The way to do this is incrementally, and the place to start is SpiderMonkey (the existing C implementation of JavaScript). So the first steps will be:

• either get SpiderMonkey to build as C++, or write a C wrapper for MMgc (leaning toward the latter)
• convince the SpiderMonkey and Tamarin build systems to cooperate
• examine the few places where SpiderMonkey is directly using malloc() and free()
• align SpiderMonkey’s jsval type and related macros with MMgc’s Atom type
• align SpiderMonkey’s notion of GC roots with MMgc’s GCRoots
• replace SpiderMonkey’s memory management routines with MMgc’s

Yeah, it gets harder as you go down the list. A lot of this work has already been done, more or less. Some patches from crowder and graydon will help. They may be a little out of date, though, and I expect it’ll take some more hacking on top of that.

Hi. I’m Jason Orendorff (jorendorff on irc), newly minted Mozilla hacker and your self-designated guide to the ongoing saga of the ActionMonkey project.

The goal of ActionMonkey is to integrate the new Tamarin JavaScript virtual machine into Mozilla. Of course, Mozilla already has a very good, very fast JavaScript VM (called SpiderMonkey). Tamarin is even faster, because it has a just-in-time compiler (JIT) that compiles JavaScript down to machine code. Firefox, of course, being increasingly written in JavaScript, craves any speed boost it can get.

But that’s not all. Tamarin is also the way forward on the memory management front. As it stands, Mozilla uses reference counting pretty heavily; it even includes a (relatively new) cycle collector that detects refcount cycles, even cycles that pass from C++ to JavaScript and back again. If that sounds a bit hairy, it is. Furthermore, SpiderMonkey’s exact GC puts a pretty big burden on the C++ developer to make sure all pointers to JavaScript objects are properly visible to the garbage collector. Tamarin contains a conservative garbage collector (called MMgc) that we would like to use throughout Mozilla to boost speed (a little) and help ease the developer pain of refcounting and exact GC.

There are also some, er, interesting challenges ahead. More on those later.