Saturday, October 14th, 2006

Mozilla 2: JIT JVM and much more

Category: Firefox

Brendan Eich has released a posting on Mozilla 2 in which he looks back at Mozilla 1 before pointing the new way.

This jumped out at me immediately:

For Mozilla 2, we will have a JIT-oriented JavaScript VM (details soon) that supports the forthcoming ECMAScript Edition 4 (“JS2”) language. Among the desirable characteristics of this VM will be a conservative, incremental garbage collector (GC). If it makes sense, we can use this GC module to manage DOM object memory instead of using XPCOM reference counting. We can use its conservative scanning code to assist in cycle collection. And we can JIT calls directly into DOM glue code entry points (provided no JS mutation has overridden a method property value), bypassing the powerful but relatively slow typelib-based dispatching machinery of XPConnect.

This will kick Ajax performance in Firefox up a notch or three.


I haven’t really begun to talk about further graphics work (3D canvas) and security models (those safe browser-based mashups). Nor have I begun to discuss Firefox 4, the likely version to be based on Mozilla 2, except to say that we will keep an unbranded Firefox version building at all times as Mozilla 2 is developed. Mainly I am focusing on the Mozilla platform, on which Firefox, its add-ons, and other apps all stand or fall.

So the goals for Mozilla 2 are:

  • Clean up our APIs to be fewer, better, and “on the outside.”
  • Simplify the Mozilla codebase to make it smaller, faster, and easier to approach and maintain.
  • Take advantage of standard language features and fast paths instead of XPCOM and ad hoc code.
  • Optimization including JIT compilation for JS2 with very fast DOM access and low memory costs.
  • Tool-time and runtime enforcement of important safety properties.

Exciting stuff. And this will push the other browsers to give us more of the same. There is also a lot more detail in the posting itself, including fun C++ code, and thoughts on where we will be with graphics.

I can’t wait to see Brendan give his keynote at The Ajax Experience in just over a week to hear more.

Posted by Dion Almaer at 1:02 am

4.2 rating from 25 votes


Comments feed TrackBack URI

Firefox 2 is available in its nightly build already from quite some time

Comment by Google Logs — October 14, 2006

Instead of JVM shouldn’t it be called something like JsVM? JVM is already taken by a well known technology :-). And seeing as how at the start of most, possibly all, Javascript books is a note on how “Javascript is not Java” then calling the Javascript VM a JVM will just lead to confusion.

Comment by Scot — October 14, 2006

Firefox 2 is available in its nightly build already from quite some time
FireFox 2 != Mozilla 2. Except for the 2 part. FTFA: “First, we should do Mozilla 2, targeting 2008”

Comment by Paradise Pete — October 14, 2006

Dion is writing about *Mozilla* 2, not Firefox 2.

Comment by Dale — October 14, 2006

“Mozilla” 2 refers to the platform.

Comment by kourge — October 14, 2006

this will not ‘speed up AJAX by a notch or three’, as it is obviously bound by network and server latency, not heavy clientside processing.

this sounds pretty disappointing to me, i would much rather see a language-agnostic VM like Parrot added to the browser, so one can use appropriately-sandboxed python or ruby clientside, as opposed to waiting another 5 years for all the ECMA members to reinvent the wheel to their standards..

Comment by carmen — October 14, 2006

carmen: Ummm.. Not sure where you think it won’t be speed up by a few notches but it most definitely will. Moving the dom operations into a friendlier vm space will be ~huge~ for all kinds of operations. Most of them having to do with UI speed and not “network” speed.

P.S., Last time I looked at the source I thought I already saw a python extension for mozilla. Maybe you need to go look again ? =p

Comment by Jesse Kuhnert — October 14, 2006

The new jitting JSVM proposal is very welcome news.
I can attest to the fact that my AJAX apps are 99% constrained by DOM node creation and rendering speed. When it takes 5+ seconds for the browser to build and render a 20 column table with 2000 rows on a 2GHz machine when only 0.2 seconds is spent on network data transfer latency – that’s just sad.
As far as the Parrot VM goes – why would Mozilla use a huge monolithic VM that even Perl6 is unable to tame after 5 years? A much better VM model to mimic would be the ultra-lightweight and fast Lua VM + LuaJIT, or Neko’s jitting VM.

Comment by Cap'n JSVM — October 15, 2006

And we can JIT calls directly into DOM glue code entry points (provided no JS mutation has overridden a method property value)

Aspect oreinted JS? Is that correct?

Comment by Ed — October 15, 2006

[…] […]

Pingback by 本日書籤 « penk - Keep on rockin’ in the free world — October 16, 2006

Hi, a few quick comments:

Scot is right: JSVM, not JVM.

Firefox is “just” a browser, not an operating system. There is no way to fit megabytes of extra VM and programming language support into it, just because someone might prefer to use another language such as Python.

Ajax developers generally want to code for multiple browsers without writing twice the code, so they’ll write in JS (or a language that compiles to JS, e.g. OpenLaszlo). They won’t write once in Python (e.g.) for Firefox, and rewrite in JS for IE and Safari.

Anyway, Firefox will support Python as an alternative scripting language for XUL extensions, and the Mozilla platform will support it for XUL applications, in a future release — but only if you arrange for the right version of the CPython runtime to be available. You can try this Python support out on the Mozilla “trunk” now.

Cap’n JSVM points the way, although we can’t use Lua specifically. The focus will be on tight code for fast JS and DOM execution, with JITted calls directly into the DOM methods where possible.


Comment by Brendan Eich — October 17, 2006

Leave a comment

You must be logged in to post a comment.