Experimental support for WebAssembly in V8

Re:Experimental support for WebAssembly in V8 by PeCaN on Tuesday March 15, 2016 @01:27PM (#11291330)

Well, you'll need a garbage collector anyway, and with AOT compilation it would have to be conservative (which isn't that much of an issue, but precise collectors are generally a little more efficient).

The problem is that you can't fully trust your type inference. JIT compilers can get away with this because they can escape to the interpreter if a type check fails. With an AOT compiler you can optimize for your inferred type but you still always have to include complete code for the slow path too. At that point 80%+ of your instruction cache is gonna be probably-unused code. You can never eliminate as many type checks as a tracing or block versioning JIT.

TypeScript doesn't help either:

  function foo(a: int, b: int) { return a + b; }
  window['fo' + String.fromCharCode(111)]('nice ', 'try);

Whoops. TypeScript is (intentionally) unsound, which doesn't help your compilation much.

If AOT compilation were a way to get JavaScript faster than V8, V8 would compile ahead-of-time (well, it would probably compile in the background and use an interpreter on first load, but you get the idea).

asm.js is a different since it is strongly typed and explicitly controls memory layout. It's not JavaScript from the perspective of implementation.

[ Parent | on HN ]

Re:Experimental support for WebAssembly in V8 by xigency on Tuesday March 15, 2016 @01:44PM (#11291493)

Well, then I should use some regular expressions, a parser generator, AST walker and syntax analyzer, with the help of a few directive comments, to turn my strict subset of JavaScript code into C, and then use emscripten to generate WebAssembly.

Then I will have faster (and smaller) code on platforms that support WebAssembly and regular JavaScript on platforms that don't.

What a wonderful way to deploy JavaScript to WebAssembly for enlightened developers, which doesn't involve a "compiler."

Obviously, we are thinking of different scenarios. My subset of JavaScript may be different than yours, which might be different than asm.js. Asm.js would be great except it isn't idiomatic and having a fixed heap isn't always great. That doesn't mean there aren't middle grounds which are as of yet unexplored. This is sort of a limited area, which is probably why no one's started a project on this yet.

By the window['foo'] argument, minifiers are unnecessary because then you can't use eval().

[ Parent | on HN ]

Re:Experimental support for WebAssembly in V8 by esailija on Tuesday March 15, 2016 @03:41PM (#11292399)

There was an experiment ("strong mode")[1] of a subset of JavaScript that is way higher level than asm.js but it failed [2].

1. https://developers.google.com/v8/experiments#strong-mode

2. https://groups.google.com/forum/#!msg/strengthen-js/ojj3TDxb...

[ Parent | on HN ]

Re:Experimental support for WebAssembly in V8 by hutzlibu on Tuesday March 15, 2016 @09:33PM (#11294384)

That is interesting, thx. ... but it seems to me, they failed, because they wanted to mix strong typed js with weak typed ... "the main problem here was the interoperability with weak classes: we need to allow inheriting strong from weak classes and vice versa"

[ Parent | on HN ]

Re:Experimental support for WebAssembly in V8 by PeCaN on Tuesday March 15, 2016 @03:23PM (#11292274)

> turn my strict subset of JavaScript code into C, and then use emscripten to generate WebAssembly.

Well, the problem there is that your subset would be... C. JavaScript without automatic memory management, closures, prototype inheritance[1], and dynamic types isn't really JS anymore.

> By the window['foo'] argument, minifiers are unnecessary because then you can't use eval().

Most minifiers don't touch object properties or global variables for this reason. Closure compiler is the only one that does and it's quite strict (and doesn't work on a lot of JS code because of it).

1. Assuming objects are hash tables in your implementation, you might be able to do inheritance by reference counting a list of parent hash tables but that could get messy.

[ Parent | on HN ]

Re:Experimental support for WebAssembly in V8 by xigency on Tuesday March 15, 2016 @05:30PM (#11293169)

The code that I have to work with is static. It just happens to be JavaScript. Aside from writing some type casts and a linked list implementation, the standard implementation for a project like this doesn't have to be large. And yes, it boils down to a trivial C compiler.

Also, Uglify 2 modifies global properties if you tell it to, and neither uglify nor closure compiler do well with object properties, which can be renamed.

All of these arguments assume that a developer is unaware or not understanding of the mechanisms that their code uses. It seems no one is interested in using anything other than emscripten/LLVM.

[ Parent | on HN ]