Project Tamarin

I just committed the initial revision of mozilla/js/tamarin, the open-source ActionScript Virtual Machine contributed by Adobe. But I had nothing to do with this fine work. It’s the product of some talented folks at Adobe (originally at Macromedia; at least one of whom has moved on and is doing a startup).

Tamarin, the open-source AVM, is the JIT-oriented JavaScript VM that I mentioned in my last post. We have already developed, via a two-day marathon hacking session, a set of proof-of-concept patches to integrate it with SpiderMonkey. The resulting Franken-VM was compiling and linking when I last laid hands on it, but not quite limping. This exercise produced many insights to guide more durable integration. And it was great fun interacting with the new open-source contributors from Adobe, whom I would like to welcome to Mozilla:

  • Jeff Dyer, self-hosting compiler architect
  • Steven Johnson, Tamarin developer
  • Tom Reilly, garbage collector developer
  • Rick Reitmaier, JIT developer
  • Dan Smith, Tamarin module owner
  • Edwin Smith, Tamarin creator and VM architect
  • Erik Tierney, Tamarin developer

My apologies to those whose names I haven’t yet learned. I’ve had the pleasure of getting to know most of the above-named folks through the ECMA TG1 (JavaScript standards) group. They are good people and skillful hackers, and I’m grateful that they are adding their strength to the Mozilla project.

I should point out that, although Adobe did not release open source for its existing, free AS3 compiler, it did contribute a self-hosting (AS3-in-AS3) compiler prototype written by Jeff Dyer. We intend to develop this jointly into an ES4/JS2 self-hosting compiler, implementing the full and final ECMA-262 Edition 4 spec when it is done. In the mean time, if you want to generate ABC for Tamarin, you have open source options.

I’ll be on IRC in a little over nine hours to chat about this great news and answer questions, and then I’m off to Web 2.0. Later this week I will blog again about some early progress on another Mozilla 2 front.

/be

Update: Frank Hecker of the Mozilla Foundation clearly and concisely answers many basic questions about What This All Means, questions to which I tend to give short shrift in this too-technical blog of mine. Recommended.

18 Replies to “Project Tamarin”

  1. How does this tie into the Mozilla 2.0 virtual machine goals you posted back in June 2004? You mentioned the need for the VM to support multiple languages (single garbage collector, etc.), but this would seem to be JavaScript-only.

  2. The goals have shifted since early 2004 (note that the blog you cite was written before Firefox 1.0). Then, it was conceivable that a single-GC, multiple-language runtime such as Mono could both (a) be small enough to fit in Firefox; (b) be free of IP encumbrances. Since then, it’s clear that we need to focus on a VM that won’t add a megabyte or more to Firefox. A true multi-language VM flunks that test.
    What’s more, we have an opportunity to join forces with Adobe and anyone else interested in bootstrapping the ES4 language, whose definition is being finalized now and into next year. We need ES4/JS2 for Mozilla XUL platform reasons, more than we want to (try to) support multiple programming languages in order to grow the platform.
    Most languages have their own runtime(s) already, so we are better off focusing on JavaScript’s runtime. Browsers do JS, not arbitrary other languages.
    So for both size and focus reasons we are targeting ES4/JS2 on Tamarin/SpiderMonkey.
    /be

  3. I should add, in case anyone fails to connect the dots, that we have supported Python for XUL scripting via optional integration with the CPython runtime. That work by Mark Hammond has been going on a while. It’s not consistent with my old blog item, either. It is consistent with the Mozilla 2 Tamarin/SpiderMonkey plan.
    /be

  4. uber great news 🙂
    so basically, someone respecting ES4 standard will be able to generate *.abc files compatible with the AS3 and JS2 runtimes/environnements ?
    If yes, then does this influence directly the
    Standard library issues proposals ?
    (https://developer.mozilla.org/es4/proposals/proposals.html)
    -> JS2 coders and AS3 coders being able to develop and share ES4 standard libraries 🙂
    does coders will be able to go as far as adding features to standard core class, for ex the String class ?
    exemple:
    people badly needing a String.format() static method which is not provided in native,
    could they take the
    mozillajstamarincoreString.as
    add directly the static method in the class
    and load the resulting String.abc in the avmplus to override/upgrade their String class ?
    (I’m interested in keeping and not changing at all the native methods, but also keeping the strict mode for speed reasons :))
    Is the avmplus package gonna be part of the ES4 standard or it’s just intended for the shell ?

  5. Somewhat off topic, but I’ve been curious to ask about ES4 type parameters. Here’s an example from the proposal:
    List.<Map.<pair.<int>, coord3d.<double> > >
    My recommendation might not look much like C++, but I find this __much__ easier to read (and I’ve done enough Java 5 and C++ to be familiar with angle brackets – don’t get me wrong):
    List of Map of (pair of int, coord3d of double)
    It also doesn’t seem out of line with the style of backwards compatibility and several new reserved words in ES4. This one single change in ES4 would just make my day.
    Anyway, great news on Tamarin. Thanks for the info and to the folks at Adobe.

  6. Toe: just to finish the thought, my own ability to foresee Firefox’s steep take-off, especially on Windows, was limited in early 2004. When Firefox did take off, I was as pleased as any pessimist could be. Since then I’ve become more focused on particular Web virtues, including JS; and less worried about making *the browser* as broad a platform as, e.g., .NET. (Whether XULRunner might want to be broader than the Firefox browser is an open question.)
    In short, I was wrong (even if premature, which is no excuse and still undemonstrated) in asserting that Mozilla (the project, or the browser Firefox) needed a multi-language-ready VM in 2004.
    Zwetan: there’s not yet any call for Firefox to load ABC files, not to say SWFs. But, library code could certainly be shared in source form among browsers, and (encoded via ABC in SWF) with the Flash Player. Your desire to hack on the standard library, while it might curl the hairs of my type-theorist friends, is good in my view, and it should be possible.
    Tom: that’s very pretty (and ML-ish) syntax, I wish we’d thought of it. It’s not too late, so I just proposed it in the ES4 wiki. Thanks!
    /be

  7. I’m very glad to hear it’s not too late, and you’re welcome. It should parse easily, too. Concerning prettiness, the worst case is with functions with type parameters (also from the wiki):
    sort of int(x) // and “sort” is an extra-degenerate case because of multiple meanings
    new Map of (string,int)()
    But I still think it comes out ahead. Anyway, I’m glad to hear you like it.
    (I have a separate Mozilla comment to make, but it fits more with your recent Mozilla 2.0 post, so I’ll add it there. It’s a bigger scope item, too.)

  8. Tom: Graydon pointed out that the parenthesized list after ‘of’ is ambiguous if you don’t always require parens, even for the case of one type parameter. This is because (T, U) is a union structural type.
    /be

  9. While we’re suggesting syntax…
    How about making a simplified function literal/lambda syntax with a built in return? Looking at what single character operators we have, I think “|” would be good to use. It’s not cumbersomely overloaded in this situation: two current cases being binary logic operators and the third being a binary logic assignment operator. Function literals cannot occur at those places, and those operators cannot occur at the places function literals can. Plus, it’s used for the same purpose in several other languages.
    So:
    var lambda=|arguments|body;
    Or with some kind of wrapping if you feel the need for it:
    var lambda=|arguments|{body};
    var lambda={|arguments|body}; // Overloading {} again, but with no conflict I can see
    var lambda=[|arguments|body]; // And overloading [] similar to what you did with generators
    The “body” part would be an expression, the result of which is also the return value.
    The biggest problem with this is that while we have conditional operator and shortcut logical operators for conditionals, we don’t have looping constructs in expression form. That could be fixed, of course.

  10. liorean: I commented at https://weblogs.mozillazine.org/roadmap/archives/2006/05/javascript_2_ecmascript_editio.html#comments with the news that for ES4, we are allowing ‘function cube(x) x*x*x’ as shorthand for today’s ‘function cube(x){return x*x*x}’. Having eliminated ‘return’ and bracing deadwood, we don’t see enough gain in eliminating ‘function’. We definitely do not favor alternative bracketing for formal parameters.
    /be

  11. Hmm. Sad on union type ambiguity. And [T, U] is an array type. Argh. The syntax is getting so full. Still, this might be okay (because of > > vs. >>), but it kills all the beauty:
    List of (Map of (pair of (int), coord3d of (double)))
    Any way that T | U could be a union type, or is overloading “|” for types themselves already allowed?
    Oh, well, I tried. I guess do what seems best.

  12. Or how about this:
    List of Map of <pair of int, coord3d of double>
    It still suffers “> >” vs. “>>”, but it would be less likely because of the ability to leave it off for single parameters (and which you can’t do for “.<” because of the existing meaning of “.”).
    But again, I’ll try to stay out of it now. I’ve chattered enough. Again, do what seems best, and thanks for considering the options.

  13. Tom, thanks for hanging in there. I’ve pitched the T of U / T of <U, V> idea. I think this kind of polishing is still possible, and potentially pretty important at this stage.
    /be

  14. Tom, sorry to say we voted and even I had to stick with “always use ‘.<>'” instead of “use ‘of’ for ‘.’ and drop the ‘<>’ if you have only one parameter”. Complexity budget wins over readability, happens all the time in programming language syntax. Too bad I was under management orders to make JS “look like Java” back in 1995. I wanted to do something more like Smalltalk, Logo, or HyperTalk.
    /be

  15. What’s the state of the ES4 spec., is there a roadmap. If I have questions about ES4 spec, where can I ask for help?
    for examples, https://developer.mozilla.org/es4/spec/chapter_20_grammar.html, it says:
    MultiplicativeExpression -> YieldExpression
    ConditionalExpression[allowLet, beta] -> YieldExpression[beta]
    first, there is no YieldExpression, only YieldExpression[beta]
    second, ConditionalExpressiona -> … -> MultiplicativeExpression -> YieldExpression
    Isn’t that cause conflicts?

  16. Eric, the normative grammar is actually in a .pdf file at the moment. We’ll get the html grammar sync’ed up.
    /be

  17. Late reply to Eric Suen’s question: “If I have questions about ES4 spec, where can I ask for help?”
    es4-discuss at mozilla.org is the mailing list — subscribe via es4-discuss-request (mailman standard operating procedure).
    /be

Comments are closed.