Mug: A New JavaScript compiler for the JVM

http://timcameronryan.com/post/2684769192/mug-javascript-compiler-for-the-jvm

by timcameronryan • 16 years ago

80 22 16 years ago

onteria• 16 years ago

Why is all the content flushed to the right? It's making it hard to read the content and actually get a sense for what Mug is all about.

pohl• 16 years ago

Seriously? There's only 4 paragraphs total. How hard can it be? It's strange that it would make it hard to read. Typographic manuals usually suggest roughly 60 characters per line, favoring narrow columns over wide columns.

al_james2• 16 years ago

This is very exciting. Will be interesting to benchmark and see what the performance is like. It would be great if you dynamically compile JS to java classes at runtime (store procedures in JS etc).

CoffeeDregs2• 16 years ago

Awesome. Question: I was under the impression (perhaps mistakenly) that it would be impossible (or very hard) to statically compile a highly dynamic language like Javascript. Yes, No? Are there shortcuts Mug takes or disallowed coding styles?

How would Mug handle the following RuPyScript pseudocode:

for i in 1..10; eval "def function$i; print 'I'm $i'; end"; end

stingraycharles• 16 years ago

I think, by definition, eval () will be impossible in a statically compiled environment.

CoffeeDregs2• 16 years ago

Right, right, but then how useful would Mug be if the dynamic stuff in JS can't be used?

timcameronryan4• 16 years ago

Right. Technically Mug will conform to the ECMAScript 3 Compact Profile: http://www.ecma-international.org/publications/files/ECMA-ST... Which doesn't include eval() or the with(){} statement (both used infrequently enough that it's not worth the overhead).

A REPL would still be possible, however, it would require some work to maintain the current scope between input.

al_james2• 16 years ago

I should imagine it wraps all values in its own flexible typed wrapper class and defines code for operations on them. This, of course, imposes quite an overhead.

timcameronryan4• 16 years ago

Sometimes. The primitive types Mug can work with are `double`, `boolean`, `String`, and `JSObject`. This allows arithmetic operations and conditionals to be compiled without wrapping objects, and actual object invocations to be autoboxed as they are in JavaScript (like "a = 10" vs "a = new Number(10)")

The gaudy part is that there is only one type of function signature, basically "invoke(Object, Object, Object...)" which means Mug has to convert doubles to Doubles and booleans to Booleans across function calls... so it's somewhat of a tradeoff.

Autre2• 16 years ago

Just tried the following:

  for (var i = 0; i < 10; i += 1)
    eval("function function_" + i + "() { print('i am ' + i); }");

  for (i = 0; i < 10; i += 1)
    this['function_' + i]();

but it seems like eval is not supported yet - i guess for good reasons.

lukev• 16 years ago

Depends what you mean by dynamic.

If you mean 'dynamically typed', then there's no particular problem - that's mainly a function of how you implement your calling protocols. It's much easier to write a dynamic compiler, actually, since you don't need to catch type errors at compile time.

If you mean 'supports eval', as your example seems to indicate, then you'll have to include either a compiler or interpreter in the language runtime - there's really no way around that. But it's not a big deal unless you're in some kind of embedded environment, and in that case you're probably not using a language that supports 'eval' anyway.

noahlt• 16 years ago

One of his strategies (from the README on Github) is "favoring static compilation rather than a runtime interpreter", so I suspect that `eval` is not included in Mug.

However, `apply` is included (cf. test/regression.js line 19). So your example pseudocode could probably be written like this:

    for (var i = 1;  i <= 10;  i++) {
        var f = function() {
            print("I'm " + i.toString());
        };
        f();
    }

timcameronryan4• 16 years ago

As al_james metioned, in order to emulate a dynamic language, you have to take a lowest-common-denominator approach. Thus all objects are of the type JSObject, which has functions for get() set() invoke() etc.-- basically a glorified HashMap+Runnable.

However, you don't need to wrap objects for arithmetic operations. At the moment Mug can determine the result of some types of expressions. If you're adding two doubles, it doesn't wrap the numbers before adding them. If you're calling (10).toString(), then it will autobox the number just as defined in the ECMAScript spec (the [[ToObject]] operation).

Deterction currently only works where types are explicit (a number literal will always be a number, etc.) The next step is to do type analysis on local variables, which will allow loops like for (var i = 0; i < 10; i++) { ... } to be compiled without wrapping primitives at all, greatly improving speed.

bokchoi• 16 years ago

Isn't Oracle also working on a new JS implementation on the JVM? I saw a job posting a while back.

Found it:

http://robilad.livejournal.com/71787.html

tlrobinson• 16 years ago

Interesting benchmark idea: run JavaScript benchmark suites through Mug then GWT, compare to original.

pjscott• 16 years ago

I'm guessing that Mug produces bytecode very different from that which you would normally want to run through GWT, and therefore might not be a very representative benchmark.

marijn• 16 years ago

Pro tip: Go straight for ECMAScript 5, don't waste your time on 3. With CL-JavaScript (http://marijnhaverbeke.nl/cl-javascript) we also thought 3 would be easier, but now we regret our decision:

- The ECMA5 document is (slightly) easier to read.

- Most 'extra' ECMA5 features can be added later, piecemeal, so initial development doesn't have to be more complicated.

- People will want ECMA5 eventually anyway.

- It is a waste of time to work through two ugly standards when one would have sufficed.

Mug: A New JavaScript compiler for the JVM

Related Stories