[apendleton]

Perhaps I'm missing something fundamental here, but my understanding of the way that JITs work is that they inspect a bunch of bytecode, then generate a bunch of machine code, then execute it. No Javascript interpreters are going to let you write executable code into a random chunk of memory and run it, so compiling a JIT with emscripten seems like a non-starter.

[ot]

Instead of generating machine code, the (guest) JIT can generate optimized JS, possibly in the asm.js fragment. The host JIT can then JIT the generated JS into optimized machine code, thus the overhead could in principle be minimal.

EDIT: If this seems too mind-bending, think that even machine code is not really machine code: the CPU actually JITs the "native" code (say, in the x86-64 ISA) into a "more native" code that is what is actually executed by the CPU (for Intel CPUs, these are "micro-ops"), and in doing that it uses a lot of compilation tricks (such as trace caches), including optimizations driven by runtime feedback (you can think of branch prediction this way).

Of course Javascript is a much thicker abstraction, but conceptually it is not much dissimilar.

[azakai]

Very correct, but a side note: asm.js might not be useful or necessary for this. asm.js makes more of a difference in large, hard to optimize codebases, and less in small amounts of code, because JS engines have been optimizing small amounts of code extremely well for a while now (using TraceMonkey, CrankShaft, DFG, IonMonkey, etc.).

Also, asm.js code is structured in a way that makes it obvious the code will not change over time (it's in a closure, where functions cannot be modified), again, in order to make optimizing large projects easier. When JITing however you do want to add new code all the time.

But this could work great without generating asm.js code. The VM itself is C code that can be compiled wholesale into asm.js (when the Lua VM was compiled that way it was quite fast, about 50% of native speed), and it would then JIT at runtime normal JS and call into that.

[slacka]

"asm.js might not be useful or necessary for this" So for situations like this, would Duetto's approach of mapping C++ objects/functions to native JavaScript objects/functions be better? If so, is this a feature that could be added in the future to Emscripten or are the designs mutually exclusive?

[azakai]

Both the emscripten/mandreel and duetto approaches map functions to functions. The difference is that duetto maps objects to objects as well.

AFAIK the duetto approach brings no benefits in this case.

[jlongster]

Yep, exactly. The JIT backend would generate js (hopefully asm.js style code), which will be further optimized and executed by the js engine down to native code.

[fosap]

You could generate a javascript (or asm.js) string and eval() it. That should be the equivalent.

[Tobu]

It does look unpromising; even something like nacl_dyncode_copy is too restrictive for the PyPy JIT (can't patch jumps).

[azakai]

You can "patch" jumps in generated JS by replacing the JITed JS function. That has overhead, but might be fine for small functions that are not JITed too often.