Friday, August 10th, 2007

The choice of Tamarin

Category: Java, JavaScript

John Resig has aggregated the Why Tamarin? debate:

What’s the advantage of Tamarin over integrating the Mono VM into Firefox?

Mike Shaver:

Here are a few, at least as I see them:

  • Optimized to run JavaScript and sibling languages, which is our most important language target by a vast margin.
  • Licensed appropriately.
  • About 1/25 the size, I think (200KB for Tamarin, 5MB for Mono as described by Miguel elsewhere)
  • In my coarse measurements, significantly smaller memory footprint.

I was once quite a supporter of getting Mono into our world, including writing a prototype XPCOM binding for it, but I didn’t see a path to getting the important factors (performance, licensing, footprint in code and memory) resolved, and I don’t think it’s much closer today. Nobody in Mono-land was interested enough to contribute to that, which is another counterpoint with Tamarin I suppose, where we have very active contributions from Adobe and others to help us get it in the state we need for it to be a suitable basis for building our whole app on.

It’s not like we didn’t look hard at Mono, and in the case of many of us lobby hard for licensing and patent concerns to be swept aside. Tamarin is a very good fit for us in a large number of ways, unfortunately including a number of ways in which Mono is not.

[Why doesn’t] Mozilla build on the Java platform rather than Tamarin?

Brendan Eich:

Moreover, for Mozilla at least, we absolutely cannot depend on closed source, and we require a non-copyleft BSD license, or at most MPL/GPL/LGPL. Java was not even open source until recently (I don’t remember the date; it was preannounced one too many times :-/), well after we had to make our own plans and commitments.

Finally, in spite of the prospects with JRuby, the JVM really is about Java first and last. Tamarin is about an ECMAScript variant, so it’s a better target now, and more likely to evolve to support JS1 and JS2 in a first class way, than the JVM.

Compilation heroics can help, but the browser will remain an environment where compilation must be very fast. Wherefore our forthcoming work on a trace-based JIT.

Then some commenters disagreed with the performance results, and claimed that a JVM would be faster but the benchmark was brought into question:

No contest indeed, Tamarin is optimized towards small footprint and instantaneous startup, compared to Hotspot. However, it can do better. If I add a return type annotation, and place a package {} declaration around the test (triggering early binding), Tamarin avoids boxing overhead, and the test results drop from 56s to 11s on my T60p, solidly inbetween Rhino-JS and pure Java.

Having a JIT running our JavaScript will be great step, however we get there.

Posted by Dion Almaer at 6:22 am
13 Comments

+++--
3.5 rating from 37 votes

13 Comments »

Comments feed TrackBack URI

Whoops, in addition to missing the included link, for bonus points I mispelled John Resig. Double points!

Comment by Lee O'Mara — August 10, 2007

The benchmarks of Tamarin vs. Spidermonkey that you referred to on the blog show that Tamarin is 20% faster than Spidermonkey on average.

http://ejohn.org/apps/js-speed/results/

Is the goal of having Tamarin 10x faster than Spidermonkey still achievable?

Comment by Confused — August 10, 2007

Confused: see

http://www.playercore.com/pub/Tamarin/Avmplus_vs._javascript.htm

Tamarin was designed to do better with type annotations than without. This is why SpiderMonkey actually wins some of those benchmarks against Tamarin on untyped code. Our work with it now in the ActionMonkey project aims to make it fast for untyped code as well.

Also, don’t be alarmed by different benchmark results. See also

http://strongtalk.org/benchmarking.html

for some healthy attitude about the perils of micro-benchmarks.

/be

Comment by Brendan Eich — August 10, 2007

It’s worth keeping in mind that Tamarin will provide minimal improvement to the large majority of JavaScript code in existence. Providing a fast implementation of ECMAScript 4th Edition is all very well, but the language itself is currently supported by zero browsers and lacks a reasonable migration path from ECMAScript 3rd Edition (aka JavaScript 1.x). Having a new version of a widely-used language with poor backwards compatibility that is being developed by only one of the four major browser developers makes me doubt that this is as important to the wider web development community as Mozilla would like people to think.

Comment by Anonymous — August 10, 2007

Spidermonkey is consistantly last place in memory usage in the Computer Language Shootout.

http://shootout.alioth.debian.org/gp4/benchmark.php?test=partialsums&lang=all&sort=kb

It often uses 100x more memory than an equivalent Lua program. Is there something in the Javascript language that makes it so memory inefficient?

The benchmark above does not even allocate memory. It’s just creating a bunch of temporaries in a tight loop. Why isn’t that memory being collected more frequently? And will Tamarin do any better?

Comment by Observer — August 11, 2007

I am a little disgruntled on the whole Tamarin thing. The work to implement IronPython, without Mono, into Tamarin, is insane. It doesn’t make sense. That language, without .Net, is just a poor Python, so what is the point? Why won’t they implement _real_ Python?

Comment by Calvin Spealman — August 11, 2007

er why not just steal the lua VM, and tweak the stdlib behavior to match JS..

Comment by carmen — August 11, 2007

Anonymous: you should identify yourself so we can see whether you’re in cahoots with MS or Yahoo!, since your comments are content-free ax-grinding of the worst political kind.

Asserting that we’ll break backward compatibility in ES4 is dumb. No one working on ES4 can afford to do that without losing market share, especially not Firefox. It’s not going to happen.

And your reading skills need work. We’ve already been over how untyped code will be optimized using runtime type feedback (trace-based JITs are perfect for this). Judging Tamarin today and assuming, or more likely just trolling, about how it will never change is not going to convince anyone. It’s classic future-tense FUD, which is why I wouldn’t be surprised if you were an MS employee or fellow-traveler.

Observer: are you also self-identifying as Confused and CrossPoster, here and in Chris Oliver’s blog? Please stick to one id and one blog. I replied to the gist of your comment @ August 11 over here:

http://blogs.sun.com/chrisoliver/entry/hotspot_vs_adobe_tamarin_vm#comment-1186842925000

where you made the same comment.

Calvin: don’t assume insanity, look deeper. We have integrated the “real” Python, C-Python, for years, going back to Mark Hammond’s work for Active State and continuing with his Mozilla-funded efforts to support Python XUL scripting. Anyone who wants to build C-Python into Firefox or XULRunner can do so (see my blog).

But again (I’ve written this many times and Pythonistas know it’s true): C-Python is neither ABI and API stable, nor small enough that we can ship it by default in Firefox, nor pre-distributed by someone with market power on Windows. So there’s no way we can count on it being already there and embeddable under a stable ABi, or distribute it ourselves.

And what’s more, C-Python has not been through the browser fuzz-tested and XSS-hacked security wars. It may be very memory safe — C-Python is quality code, and IIRC subject to some fuzzing — but it as yet has no integration with the same-origin browser security model, and it would be yet another attack surface if integrated.

We much prefer memory-safe implementation languages.

IronMonkey is all about downloadable, memory-safe and (we plan on this) high performance Python and Ruby for Tamarin. You don’t need “.NET” for this. We may have to diverge from the MS-run Iron projects at some point in order to pull this off, but only if it’s justified on technical or governance grounds. Only if, as you worry, the Iron versions are not close enough to the “real” versions of these languages in compatibility and performance.

carmen: why not “steal” any open source VM and rewrite it to implement ECMAScript? If time were free, and we weren’t working on Tamarin already with Adobe, which ships it to 90%+ of desktops, then maybe. But that’s a dream world, not the real world, and there’s no distribution upside to Lua (I like Lua fine technically, don’t get me wrong).

BTW, have you heard about ScreamingMonkey?

/be

Comment by Brendan Eich — August 11, 2007

One more point in reply to Calvin’s comment:

Memory safety is a strong enough reason by itself to avoid C-Python, and I mentioned size and lack of security model integration and other reasons. But I left out a big one: cross-language memory cycles. These are a real problem in browsers today, where the two languages are JS and C++. They’ve always been an unfixed bug in any LiveConnect that bridges Java and a non-Java-based JS (i.e., not Rhino). In Mozilla, we’ve been working hard to fix all cycle-created memory leaks, using a general cycle collector (again, see my blog) to ship in Firefox 3.

But if we were to try to integrate C-Python and whatever’s going for Ruby in the way of a native-code runtime, besides all the other problems I’ve listed, we would have to integrate these runtimes with our cycle collector. This is non-trivial and invasive.

Maybe this is too much technical detail, but it all adds up and I wanted to add to the list :-/.

/be

Comment by Brendan Eich — August 11, 2007

It’s interesting to hear that Java’s JVM was considered. Most of this discussion is around performance, and licensing. Has there been any discussion around the immediate ability to reuse existing development tools? One of the most frustrating things in doing heavy Javascript web development is the lack of decent tools, predictable threading models, memory models, etc. Then there is performance tools, memory leak detection, etc. A big advantage of using the JVM would be immediate access to the existing tools.

Comment by Charlie Hubbard — August 13, 2007

Charlie: you’ve read the reasons why a JVM is not happening, and tools won’t overcome those. Also, a lot of Java tooling is for Java, not for JS. The use of JS is on the web as a source langauge embedded and loaded from HTML is not going away or being replaced by Java any time soon.

For better tools over time, see Firebug, and look at Aptana if you get a chance — pretty slick.

/be

Comment by Brendan Eich — August 13, 2007

Hey great comments. I am sure I can use this for our website http://www.caledongardens.com

Comment by Frans Holenberg — November 17, 2007

While reading and reacting to a recent post about “Ruby for Tamarin vs JRuby, Erlang in Javascript vs Erlang in Java”, I just want to suggest my one-year-old post Why not running a Java Browser Edition on top of Firefox VM (Tamarin) ?. I think this subject is still worth questioning, as this should lead to a faster Java startup, as this VM will be running as soon as Firefox is running too. So, I am naively wondering: why not a cooperation between SUN and Mozilla about it ? I think both parts would benefit from such cooperation.

Comment by dmdevito — January 2, 2008

Leave a comment

You must be logged in to post a comment.