After yesterday’s post on the browser scripting revolution, detailing the new projects being built on top of Tamarin, a number of questions came up concerning the choice of Tamarin instead of other virtual machines. Two engines came up, in particular: The Java Virtual Machine (JVM) – which is already able to run Jython and JRuby, and Mono – which is able to run IronPython and IronRuby.
I’ll defer to the words of Mike Shaver and Brendan Eich to explain the reasons as to why, though in a nutshell: The non-technical reasons for choosing Tamarin are over intellectual property and licensing issues and the technical issues are related to compilation speed, file size, and memory footprint.
What’s the advantage of Tamarin over integrating the Mono VM into Firefox?
Here are a few, at least as I see them:
* 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?
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.
Stephan Schmidt (August 9, 2007 at 2:40 am)
I think this has more to do with Java hate and politics (Adobe and Flex comes to mind) than with technological considerations.
Especially all comments by Brendan are straw men arguments:
“My point was in the context of the Web as the contested ground, not intranets; and the Web is where Flash has effectively vanquished Java. You can find real estate virtual tours that use Java, but the defaults are always Flash, always load faster, and always perform better. Same with Flash games vs. Java games. The ubiquity of the Flash plugin compared to an up-to-date JRE is another data point.”
“We’ve made our reasoning crystal clear, and until this year, without open source Java, there was *no way* to integrate a JVM as the VM underlying.”
Again mixing the VM issue with the JDK. There are Java Hotspot VMs which are open source VMs around.
Not that Tamarin is a good thing for Firefox, as currently FF is much too slow for some JS applications. And perhaps someone should fix FF on MacOS X, it consumes too many resources after one week of constant work.
Stephan Schmidt :: firstname.lastname@example.org
Reposita Open Source – Monitor your software development
Blog at http://stephan.reposita.org – No signal. No noise.
Doug (August 9, 2007 at 9:59 am)
Steve Goguen (August 9, 2007 at 10:18 am)
I’m just returning from the link *you* sent me to and I can’t believe all of the bullshit you’re spewing here. It’s like you didn’t even bother to read Brenden’s dozen or so comments he made, as he was desperately defending Mozilla’s decision to use Tamaren.
You say there were open source JVMs *before* the decision, but you totally ignore Brenden talking to JVM project leaders who themselves told Brenden their footprint was way too big and nowhere near ready.
BTW, You talk of Java hate and politics, but you seem to be the only one who’s putting the topic in that context. It’s like you’re a shill for Sun who’s been dispatched to search out blogs, attacking Mozilla’s decision not to use the JVM as the engine.
You rhetorically ask, “Could we please focus on VM technologies?” and then in the same breath post a diatribe about “Java hate and politics” with “Brendan[‘s]…straw men arguments” taken out of context.
Maybe you’ll start questioning my motivation too for calling you on your bullshit. In case you’re wondering, I’m some asshole who works on some shitty internal business system and I’ve never pledged any allegiances to a technology, well… except maybe for jQuery. :)
Seriously, it’s that good.
whoops (August 9, 2007 at 10:21 am)
tamarin was the right choice
first and foremost this engine needs to execute existing js well. tamarin is a known quantity here.
what i would like to know is if john sees any value in tamarin delivering on one promise of .net (and cil), namely the ability for language X to use libraries written in language Y
Jon Smirl (August 9, 2007 at 2:48 pm)
Another choice was to use the tiny mobile JVM for the main Mozilla download then switch to hotspot if it was installed.
The only real reason I ever heard for not going JVM was that the JVMs were only licensed GPL which was incompatible with MPL/GPL/LGPL. If the JVMs were licensed CDDL/GPL they would have been compatible with MPL/GPL/LGPL but no one from Mozilla asked Sun to do a dual CDDL/GPL license.
I already have too many VMs. We don’t need more of them.
Mike Shaver (August 9, 2007 at 2:54 pm)
I’m not that concerned about IP issues, as I think they could be resolved to within epsilon of our current state if the technical barriers were overcome. The technical barriers are significant though, especially in the area of footprint and suitability for dynamic languages. Tamarin is a good technology path for us, speaking as someone who looked long and hard at Mono as a VM underpinning for Mozilla for quite some time. There may be better choices today for multi-language general purpose VMs, but from the perspective of a JS-family engine with very tuned memory and code-size footprint and proven robustness in hundreds of millions of deployed clients, there’s nothing out there that’s even close today.
Mike Shaver (August 9, 2007 at 3:02 pm)
Jon: we’ve been asking Sun to do various open source licensing things that would be compatible with us for almost a decade now, of course. :)
You already get the SpiderMonkey VM today, and you’ll get the Tamarin VM instead; you needn’t worry about the internal switch if you don’t want to.
Brendan Eich (August 9, 2007 at 5:49 pm)
Stephan: please re-read Chris’s blog. Ed Smith posted about how the AS3 version of the Tak benchmark that Chris wrote was not completely type-annotated and package-wrapped. It’s unfortunate that such Java-like additions to it are needed to give Java-like performance, but they are. To be fixed as part of ActionMonkey and the ES4 (JS2) work on Tamarin.
Anyway, Ed’s results put Tamarin within striking distance of Java, and much faster than Rhino.
Too bad that blog item’s title/headline didn’t change to reflect the apples-to-apples comparison.
L (August 11, 2007 at 10:13 am)
What about LLVM? I’ve heard great things about it, but no one except for apple seems to be interested…
email@example.com (September 5, 2007 at 2:18 pm)
tlps wavokhb vjzauxl foesacnp oaczwq esxctvobk meqcoawd
no problem (October 6, 2007 at 10:21 pm)
I don’t see what all the fuss is about. Moonlight will work with Mozilla. Tamarin will work with Mozilla. Probably some JVM will work with Mozilla, eventually. Mozilla will support everything.