- From: Alexey Andreev <konsoletyper@gmail.com>
- Date: Sat, 3 Sep 2016 23:45:55 +0300
- To: Luke Briggs <luke@kulestar.com>
- Cc: public-webassembly@w3.org
> An important note, from what I can tell from your project, is that you > might be taking the wrong approach. WebAssembly doesn't currently have > GC - you've got to manually allocate memory so outputting WebAssembly > is very different from outputting JavaScript source as your project > currently does. Thank you for the warning, but I already know it. I wrote an LLVM prototype several months ago, which had (non-incremental, non-relocating) GC. As my current employer is not interested in LLVM, but interested in prototyping for WebAssembly, they allowed me to use bit of my working time for WebAssembly support. Of course, I'm focused on WebAssembly, but with LLVM in mind. I'm going to port all I've done for LLVM generator to WebAssembly. Both GC and exception handling require to walk stack, which is currently unsupported in WebAssembly (and, frankly speaking, poorly supported in LLVM), so I'm going to implement shadow stack. Shadow stack is easier to maintain in LLVM, since it allows to get pointers to local variables. In WebAssembly I'll have to allocate/deallocate shadow stack on "heap". Shadow stack gives some overhead, but it can be reduced by properly used results of liveness analysis and inlining (inlining reduces number of calls and therefore reduces number of allocations/deallocations and local var spills). Zero-overhead exception handling requires not only to read stack, but also to unwind it, which is also impossible in WebAssembly. However, it's possible to generate a small check after each invocation, which of course introduces some overhead. Anyway, with all these overheads LLVM generator for TeaVM has shown relatively good performance. > What others have typically been trying is port a C++ Java VM through > to WebAssembly via Emscripten with mixed success. What's this C++ JVM gonna to do? Interpret bytecode? It's slow. It currently can't JIT in WebAssembly, so you have to find AOT JVM, something like RoboVM, MOE. Another option is TeaVM, which is also a AOT JVM, and it's not that hard to improve it. > As for the actual errors you're seeing, it seems like you're missing > some value(s) from your wasm stream and it's basically going out of > alignment. Yes, it seems to be true. But in case of ml_proto I could compile it with -g option and run it with ocamldebug. I used this when I fixed my initial bugs in binary emitter. As for Firefox or Chrome, they are too huge for me to understand how to build and debug them. Another problem is browsers produce the same messages when I compile wast with ml_proto. > I haven't taken a look at your source yet though so the best thing to > do would be open up an issue on the WebAssembly Github design repo > (https://github.com/WebAssembly/design) and reference your source > file(s) which output the wasm. I guess I can, but people have to understand how my generator actually works. I thought it'd be easier to provide existing generated file instead. Also, the problem is not directly related to design repository, it's related to browsers.
Received on Saturday, 3 September 2016 20:46:28 UTC