One of the funny little benefits of switching the Mozilla Developer Center from MediaWiki to Deki is that page names can contain actual underscores. The big headline on the JS_EvaluateScript page always used to say “JS EvaluateScript”.
Well, not anymore! Since Deki has an HTTP API, I was able to write a Python script to fix the titles of all the JSAPI pages at once. The source code includes a Python module for loading and saving Deki wiki pages. Enjoy!
Thanks to Ben Hearsum and Ted Mielczarek, the Try server has a cool new feature: you can now try out some changes without manually creating and uploading a patch. Just hg commit or hg qrefresh your work, and then
hg push -f ssh://hg.mozilla.org/try/
The Try server will kick off Linux, Windows, and Mac builds with all your latest changes. Specifically, it’ll build your hg tip revision.
Details:
If you’re using Mercurial Queues, this push command pushes any patches that are currently applied, and the Try server will build the result. (This is an awesome feature, not a bug!)
If you’ve ever pushed anything to mozilla-central, you already have the right permissions to do this. If not, see the Mercurial FAQ for more information about pushing.
The Try server wiki page has more information about the Try server, including where to find the finished builds.
You don’t need to clone or pull from the try repo, and you probably don’t want to. You’d get every half-baked changeset anybody ever tested.
You can abbreviate the push command even further. If you add these lines to your $HOME/.hgrc file:
[paths] try = ssh://hg.mozilla.org/try/
then the command becomes hg push -f try. Or you could use a script or an alias.
Brad Lassey recently vented some understandable frustration with Mercurial, the new distributed version control system we’re using for Mozilla 2 development.
I sympathize with Brad, especially because almost all of the comments seem to be along the lines of “No no, you’re mistaken, Mercurial makes things easier, not harder” or “Well, you should have done X,” without understanding Brad’s problem.
Still, I think Brad’s frustration is somewhat misplaced. The other side of the story involves Windows Vista. Brad did some work in a Mercurial repo on Vista, then zipped up the whole repo and moved it to a Windows XP VM. This is supposed to work just fine. But (and this part, we think, this is due to a brilliant top-secret feature of Windows Vista called virtualization, a feature so awful the mobile developers have resorted to logging in as Administrator all the time) Brad ended up with a zip file that had multiple copies of some files. Whatever Vista put into that zip, extracting it on XP produced a corrupt repository. (Specifically, Mercurial’s working directory was at revision X, but it thought it was at revision Y.)
Mercurial is different in a lot of ways. Compared to CVS, it’s more flexible and more complex. Mercurial vs. CVS reminds me of C++ vs. C:
After ten years of ups and downs with C++, I’ve made my peace with it and wouldn’t want to go back to pure C.
Update: It turns out Brad’s problem was at least partly caused by the Mercurial binary distribution he was using. The default hgmerge script was broken in an exciting way. I believe it’s fixed in the latest binary distribution.
This is cool (if you care how malloc() works, always a big if), but it requires a lot of background.
One very common way to implement malloc() is to use size classes and freelists. If you already know all about this, skip this section.
Here’s a sample malloc() that uses size classes and freelists. (Note that size classes have nothing to do with the object-oriented notion of a class.)
void * malloc(size_t nbytes)
{
/* Say you want 24 bytes. Well, there's an allocator that
* specifically serves up 24-byte chunks of memory. (Actually
* if you ask for 21, 22, or 23 bytes, you'll probably get the
* same allocator.) This is what I mean by size classes.
*/
FixedSizeAllocator *allocator = getAllocatorForSize(nbytes);
/* Each allocator maintains a linked list of free buffers.
* This is what I mean by freelists. Usually there's
* something in the freelist, so allocation
* is super-fast. But occasionally it's empty.
*/
if (allocator->freelist == NULL)
return allocateNewBuf(allocator); /* (the slow path) */
/* The super-fast path. Just pop the first item off the freelist. */
void *item = allocator->freelist;
allocator->freelist = LINKED_LIST_NEXT(item);
return item; /* man, that was fast! */
}
/* free() is super-fast, too. */
void free(void *buf)
{
/* First get the allocator... */
size_t bufsize = GET_SIZE_OF_BUF(buf); /* (usually stashed nearby) */
FixedSizeAllocator *allocator = getAllocatorForSize(bufsize);
/* Then just push this buffer back onto the freelist. Zoom zoom! */
LINKED_LIST_NEXT(item) = allocator->freelist;
allocator->freelist = item;
}
See how simple and fast that is? Even if all the freelists are initially empty, each time you free() memory, it goes on a freelist. So pretty soon, almost every call to malloc() is just popping a ready buffer off a linked list.
I’m glossing over allocateNewBuf() here, but it doesn’t have to be complicated. Basically it just asks the OS for pages of memory in chunks of, say, 4KB; and treats it as an array of smaller chunks, returning the next chunk in the array each time it’s called.
It all seems pretty awesome, right? It did to me. Then one day Brendan Eich mentioned to me that this approach can lead to fragmentation.
That surprised me. After all, the point of size classes is to avoid the fragmentation you get if you try to allocate buffers of all sizes from the same heap. Google for “best-fit” or “first-fit”—the results are all about heap fragmentation.
Now, in case you haven’t met Brendan, I should explain a bit. He talks fast and he says amazing things. His speech is full of metaphors you might need to think about for a while in a quiet room and examples you’ve never heard of. The average word Brendan uses is rarer than the average word you or I use. So Brendan’s output is ludicrously high-bandwidth, often impossible to keep up with; but at least you can Google what you don’t understand. Spending a few days puzzling over what Brendan meant by some five-word off-the-cuff remark, and ultimately decompressing it into a rewarding insight, is merely typical. At least, for me. No exaggeration.
In this case, I eventually found out Brendan was referring to a different, and potentially much worse kind of heap fragmentation than the kind I was familiar with. At program startup, ten calls to malloc(24) will typically return ten buffers that are close together in memory. Maybe even right next to each other, like an array. This is by design. It provides great cache locality and page locality. But as time goes by, the application free()s buffers in no particular order, so the freelists tend to get shuffled. Eventually, ten calls to malloc(24) might return pointers into ten different pages of otherwise unused memory: the worst possible locality.
This weekend I suddenly realized that MMgc’s fast malloc-like allocator, MMgc::FixedMalloc—a piece of code I read months ago—contains a clever workaround for this problem!
FixedMalloc uses per-page freelists. Each fixed-size allocator has a linked list of pages. Each page has a freelist for the buffers in that page. malloc() always consumes one page’s freelist completely before going to another page.
I’m sure this trick is well-known in the field, but what’s a blog for, if not advertising your own ignorance?
I just posted to mozilla.dev.platform about Mozilla 2 platform changes. In short: Mercurial is coming, Tamarin is coming, and we’re going to give garbage collection a chance to prove itself.
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.
. It also converts + signs to spaces. Quaint bug, very 1995. If you know of a better converter that requires no download, let me know.)- 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”.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 notpeter: ok good because I never heard of such things! jorendorff: Happy to explain.
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
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.
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
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.