Rooftop lab

Want to help the Mozilla project? Here’s something anyone with a web browser can help with.

A lot of technical documents still live on www.mozilla.org. This is bad for a lot of reasons, but fundamentally it’s just the wrong place for them. developer.mozilla.org is their proper home. The pages will be much easier for us all to find, improve, and maintain there.

You can help migrate this content.

• Find a page to migrate. MDC:Existing Content is the nerve center of this operation and contains a huge list. (Seasoned hackers might prefer to grab the source code for the entire www.mozilla.org web site from CVS and use their best judgment about what to migrate. Some things are clearly technical docs; some aren’t.)
• View → Page Source. Copy the HTML code for the page.
• Paste it into an HTML to Wiki converter. (Unfortunately, this one has a few bugs. Watch for glitches with non-ASCII characters like  . It also converts + signs to spaces. Quaint bug, very 1995. If you know of a better converter that requires no download, let me know.)
• Make a new page on developer.mozilla.org. The easiest way is to edit MDC:Existing Content, find the link that you’re about to migrate, and add: - now migrating to [[Title of the new page you want to make]]. Click Save Page. Now MDC:Existing Content should have a red link (you just added it). Click the link to go to the new, empty page, then click “edit this page”.
• Paste in the Wiki code. In the Summary field, write “migrated from ” and paste in the URL of the old www.mozilla.org page. Click “Save Page”.
• Look at the new page. If it looks awful in any way, click the “Edit” link on the right-hand side and clean it up. (the “Editing help” link might help you figure out what’s wrong).
• Follow the 5 After Document Migration steps to make sure (a) people can find your new page; and (b) nobody else does the same work all over again.

See? Easy and fun. This is what I do now when something’s building. So far I’ve migrated 23 pages.

If you really want a new best friend, write an extension to make this process less ridiculous.

Maybe you’re curious about how the MMgc garbage collector works. Here’s my rambling attempt to explain it on IRC this morning (edited for clarity and layout).

(Note: The MMgc documentation is another good place to start, if you already know all about the C++ stack and heap.)

peter: this "scanning the C stack" is a mystery to me
peter: I had no idea C was reflective like this
jorendorff: Oh, it's not 
peter: ok good because I never heard of such things!
jorendorff: Happy to explain.  
jorendorff: Or try. 
jorendorff: But you need to understand a little about how C works in practice.
jorendorff: What do you know about "the stack"?
peter: not much I guess
peter: I know about regular C dynamic memory use
jorendorff: Well, when your program runs, and main() gets called,
jorendorff: say you've got some local variables in there.
jorendorff: C has to store them somewhere.  What happens is
jorendorff: ...C has some memory, maybe 64K bytes, set aside
jorendorff: ...for local variables.
peter: yep
peter: set aside by the OS, correct?
jorendorff: eh, not exactly
jorendorff: C asks the OS for 64K bytes, the OS says sure, here you go,
peter: right
peter: ok
jorendorff: ...and C uses those for the stack.
jorendorff: But the OS doesn't know what C is doing with them.
peter: ok

Here when I talk about “C” doing things, I really mean “the C language runtime”. This is code that the C linker automatically links into every C/C++ program. It’s called libc on Unix. On Windows, they call it the CRT.

jorendorff: So.  C remembers how much of the stack is in use.
jorendorff: (It has a machine register pointing to "the top of the stack")
jorendorff: (...on intel x86, this is ESP)
peter: C's malloc asks for memory from this 64kb and manages it
peter: making sure things that need to be in even alignment, are
peter: and so on
jorendorff: Well, the stack is separate from all malloc'd memory.
peter: ahh ok
jorendorff: Local variables don't go in malloc'd memory.
peter: gotcha
jorendorff: C actually sets up both the stack and the malloc() heap
jorendorff: before main even runs.
peter: ok
peter: and the stack is the automanaged part for locals
jorendorff: exactly
peter: thats the part everyone likes 
jorendorff: right.
jorendorff: OK.  So when main() calls another function,
jorendorff: ...say it calls printf()
jorendorff: C does all this automatically
jorendorff: ...*before* any code in printf() actually executes:
jorendorff: (1) stores a "return address"
jorendorff: so it knows where to pick up again when printf() eventually returns
jorendorff: (2) sets aside some stack space for printf's local variables.
jorendorff: I guess (2) actually happens in some code within printf
jorendorff: ...that is generated automatically by the compiler.
jorendorff: Then printf() runs.
peter: ok
jorendorff: When printf() returns, all those local variables go away.
jorendorff: My point is--
jorendorff: can you see what the data structure for this is like?
jorendorff: "The stack" is just a contiguous chunk of memory.
jorendorff: main()'s locals are at the bottom.
peter: sure
jorendorff: If main() calls another function, those locals are adjacent
jorendorff: and so on
peter: makes sense
jorendorff: it's actually a "stack" in the data structures sense.
jorendorff: ok, what this means is
jorendorff: all local variables, both for the current function
jorendorff: and all its callers,
jorendorff: are in this contiguous chunk of memory.
jorendorff: For each platform (meaning, OS + CPU + compiler)
jorendorff: ...there's a way to find out where that chunk of memory is.
jorendorff: Tamarin does that,
jorendorff: then it scans all that memory during GC
jorendorff: to see where the locals point to.
peter: there is some C header can be included that allows access to all this?
jorendorff: peter: not standard C, no
peter: no but some header
jorendorff: yeah, look in the tamarin source  

This magic lives in a macro, MMGC_GET_STACK_EXTENTS, defined in the header MMgc/GC.h. As you can see, there’s a separate implementation for each platform.

At any given moment, some locals might be in CPU registers and not on the stack. To cope with this, the macro uses a few lines of assembly code to dump the contents of all the registers onto the stack. That way MMgc can just scan the stack and it’ll see all local variables.

peter: I have been thinking there would be ways to fool this stack scan
jorendorff: peter: Yes, there would be.  
jorendorff: Can you give me an example, though?
peter: if a local pointer points to  dynamically allocated bit of memory
peter: that points to other dynamically allocated bits
peter: that should not be garbage collected
peter: and there have been a bunch of type casts along the way
jorendorff: Oh, type casts don't affect MMgc at all.
jorendorff: MMgc doesn't look at C/C++ code.
jorendorff: It's looking at raw memory.
peter: ahh right
peter: just inference by bit patterns?
jorendorff: yep
peter: and it follows from local pointers to malloc()ed memory,
peter: and follows the pointers in that memory to other memory, and so on?
jorendorff: yes, in principle -- but
jorendorff: MMgc has its own allocator
jorendorff: that you must use instead of malloc().
peter: ahh
peter: ok
jorendorff: Since it knows all the internal data structures
jorendorff: used by that allocator,
jorendorff: when it follows pointers
jorendorff: it knows the size of every region
jorendorff: and can scan each reachable region for further pointers.

In addition, MMgc does enough bookkeeping that it knows exactly which parts of memory are GC-managed. So it can’t be fooled into following a pointer into bad memory (such as NULL or a pointer to a page of memory that has been returned to the operating system, either of which would immediately crash the process). The same bookkeeping information helps MMgc avoid mistakenly writing to non-GC-managed memory. (This matters because it does write to GC-managed memory, just like any other mark-and-sweep garbage collector.)

There are other ways to fool MMgc. Simply using malloc() is enough —MMgc never scans memory allocated using malloc(). It’s up to the programmer to avoid fooling MMgc. This is not such a heavy burden in practice.

peter: fascinating stuff
peter: who's the genius that thought up all this stuff?
jorendorff: Some Lisp hacker in prehistory 
jorendorff: 
jorendorff: Lisp was the first language with GC
jorendorff: you can look up garbage collection online
jorendorff: It's a whole field of computer science.
jorendorff: It *is* fascinating.
peter: do you know the proper comp sci terminology
peter: for this stack-scan style of GC?
peter: or is it just part of the collective knowledge?
jorendorff: Um,
jorendorff: What MMgc does is called "conservative GC"
jorendorff: which means (a) it doesn't really know the types of variables,
jorendorff: so it scans everything whether it's really a pointer variable or not
peter: ok I've seen that written in a few places recently
jorendorff: and usually (b) it treats all the likely places as "roots"
jorendorff: including the stack
peter: The root of the issue is I had no idea C could analyze it's own stack
jorendorff: heh
jorendorff: C can do anything  

Indeed it can—which is why, despite their many deep, fundamental problems, C and C++ remain the weapons of choice for operating system and VM designers.

For the past 4 weeks or so, Ed Lee and I have been incrementally nudging the actionmonkey repository toward a state where we can switch over from SpiderMonkey’s existing memory management routines to Tamarin’s memory management library, MMgc.

Today some key patches for ActionMonkey Stage 0 were posted on bug 391211. These patches delete the old JSGCArena scheme and start allocating everything—JavaScript strings, functions, objects, and more—from MMgc.

This change will lead to several simplifications. For example, SpiderMonkey currently saves a reference to every new object as it’s created. This reference keeps the object alive in case GC happens while it’s new, before it’s reachable from other data. The reference lasts until the next object is created. So as long as you know SpiderMonkey internals reeeally well, and you’re dead certain no new objects are being created, you can sometimes avoid explicitly rooting an object. Hmmm, maybe this sounds a little crazy and brittle… anyway, these “newborn roots” will be unnecessary with MMgc, because MMgc scans the C stack. Even if your new object isn’t reachable from anywhere else yet, there will be a pointer to it from the stack or registers, so it won’t be unexpectedly collected. Similarly, throughout SpiderMonkey, JSTempValueRooters are used to pin objects referenced by local variables in C code. These temporary roots are generally short-lived, whereas GC happens rarely; so adding and removing the temporary root is just useless bookkeeping most of the time. Thanks to MMgc’s stack scanning, these TempValueRooters can be deleted altogether. And third, we’re planning to delete some bits called GCThingFlags that currently cost us 4 to 8 bytes per allocation. I’m curious to see how these simplifications will affect performance.

These cleanup tasks are an easy way to get involved in ActionMonkey, by the way. Leave a comment if you’d like to lend a hand.

ActionMonkey dwells on the frontier of Mozilla. Its source code lives in a Mercurial repository, not CVS. There is no Tinderbox and no Bonsai. Worse, the usual build instructions don’t quite work in ActionMonkey-land, and until now, just building it has involved a lot of guesswork.

Today, some kind-hearted genius updated the ActionMonkey wiki page with build instructions. The current status of these instructions is “it probably works on Mac OS”. And I want to make it clear exactly what you’re getting if you build ActionMonkey today. It’s just SpiderMonkey with a few Tamarin genes grafted in, but still inactive. It’s very, very early in the game yet.

If life on the frontier is your thing, please take ActionMonkey for a spin. You can really help us by reporting build system bugs—especially on Windows and Linux. If you do report a bug, please assign it to jorendorff.

Stage 0 of the ActionMonkey project is underway. Read all about it. Mardak and I are replacing SpiderMonkey’s garbage collector with the new Tamarin garbage collector, which is called MMgc (for MacroMedia garbage collector—nobody ever renames anything :).

We’ve spent the past month almost entirely in preparation for this day. I’ve read a lot of source code, drawn strange little diagrams, blown away lots and lots of Mercurial repositories, hacked Makefiles, and made a fool of myself on IRC. Mardak and I have even filed and fixed a few Stage 0 bugs. But we haven’t changed anything that would break SpiderMonkey. We were making sure all the pieces are in place first.

Today’s the day. (see update)

You can help! Review our changes. Check our thinking. Or just take the opportunity to learn how a real-world garbage collector works. Getting involved is super easy. Log onto Mozilla’s IRC server, irc://irc.mozilla.org/mmgc and say my name (jorendorff). (If the link doesn’t work for you, try the ChatZilla add-on.)

Update: Yikes! Today is not the day. At Brendan’s prodding, we have hit upon a safer plan that may avoid breaking SpiderMonkey altogether. More to come.

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.