asm.js

[KOLANICH]

We need asm.js support. (there was an issue, it is closed now, but I have a counterargument). We can use asm.js only in that functions which can be converted into it. To enable asm.js in a function we need a prologue "use asm";

[kg]

I was told very strongly not to bother using ASM.js v1 in JSIL output. Once ASM.js v2 is available work will be done to support it.

[wizzard0]

Interesting! Maybe you have a link about changes expected in v2?

[kg]

ASM.js v2 adds garbage collection integration, such that it would be possible to use the JS GC and heap objects. Implementing our own GC is not an option and that's the main thing that rules out ASM.js.

The other main problem is that the ASM.js FFI is pretty slow, so even if we were to take hotspot code in JSIL, somehow convert it such that it never touches the GC heap, and emit ASM.js code - we'd pay transition costs every time we call into those hotspots, potentially coming out behind.

There are some other problems too (it's not possible to pass JS objects around as opaque pointers, for example, so we'd have to manually 'root' any JS object touched by ASM.js) but those two are the main ones.

[wizzard0]

Oh I see. That's rough.

[JeroMiya]

FYI: It looks like there is some movement on the OdimMonkey FFI slowness issue: https://bugzilla.mozilla.org/show_bug.cgi?id=982036

[kg]

For reference, ES Typed Object integration and ASM.JS v2 integration are both being sponsored currently. I have no idea when they will land, of course, but you can consider this in-progress.

As a stopgap, at some point support for generating ASM.JS v1 code for simple C# functions will land. I don't know if it will be realistically usable in large programs but it might let you compile simple libraries.

[kg]

This effort currently lives in the es7 branch. No promises, of course :-)