4 ms·

> For similar reasons the architecture of V8 in particular has effectively dictated the design of WebAssembly, especially regarding control flow constructs like

> For similar reasons the architecture of V8 in particular has effectively dictated the design of WebAssembly, especially regarding control flow constructs like goto and coroutines. The weirdness of WebAssembly with regards to control flow constructs is rooted in Emscripten's "relooper", which was developed in a naive manner ignoring previous (superior) research on irreducible control flow.

kevingadd 7y ago
Yes, but in both cases this is because the JS runtimes (v8 in particular) makes it really difficult to feel okay with unconstrained control flow. The relooper may have been an influence but it was primarily pressure from the v8 people (I was in these meetings) I'm less certain on my memory but I recall that Spidermonkey was more easily able to do fancier things with control flow.
- cwzwarich 7y ago
  I worked at Mozilla Research in the early days of Asm.js and sat next to that team. I would frequently tell them that they should support arbitrary control flow, and that there were better ways to achieve it with Emscripten than the Relooper. There wasn't much interest in improvements at the time, although it appears that the LLVM WebAssembly backend now uses a better approach. While SpiderMonkey itself might support fancier things with control-flow, they were writing a separate compiler for Asm.js that relied on structured control flow for SSA construction, but I have no experience with how things evolved after that. Reading the thread at https://github.com/WebAssembly/design/issues/796 https://github.com/WebAssembly/design/issues/796, it seems that V8 and SpiderMonkey have roughly equivalent design constraints.
saurik 7y ago
I am pretty sure the reason for this is that alternative designs for control flow cannot be implemented in linear time; Java, for example, has experienced epic denial of service attack issues on their verifier design, where code of specific forms leads to quadratic verification time.
- cwzwarich 7y ago
  There are a few different performance issues with the Java bytecode verifier. Are you referring to this one? https://pdfs.semanticscholar.org/7dd2/b5359ab507fec1b1223db6edf5f58f9a28b6.pdf https://pdfs.semanticscholar.org/7dd2/b5359ab507fec1b1223db6... The cause of this is that the dataflow analysis performs nontrivial merging of dataflow facts, requiring a reanalysis. In the WebAssembly design there is no merging; any divergence of stack effects is an error. There are other deeper issues with the Java design: bytecode subroutines, the fact that the Java subtype relation doesn't form a semilattice, and way in which Java bytecode models object initialization.
ghusbands 7y ago
I have an interest in this - can you point at the earlier, superior research, please?

kevingadd 7y ago

Yes, but in both cases this is because the JS runtimes (v8 in particular) makes it really difficult to feel okay with unconstrained control flow. The relooper may have been an influence but it was primarily pressure from the v8 people (I was in these meetings) I'm less certain on my memory but I recall that Spidermonkey was more easily able to do fancier things with control flow.

cwzwarich 7y ago
I worked at Mozilla Research in the early days of Asm.js and sat next to that team. I would frequently tell them that they should support arbitrary control flow, and that there were better ways to achieve it with Emscripten than the Relooper. There wasn't much interest in improvements at the time, although it appears that the LLVM WebAssembly backend now uses a better approach. While SpiderMonkey itself might support fancier things with control-flow, they were writing a separate compiler for Asm.js that relied on structured control flow for SSA construction, but I have no experience with how things evolved after that. Reading the thread at https://github.com/WebAssembly/design/issues/796 https://github.com/WebAssembly/design/issues/796, it seems that V8 and SpiderMonkey have roughly equivalent design constraints.

saurik 7y ago

I am pretty sure the reason for this is that alternative designs for control flow cannot be implemented in linear time; Java, for example, has experienced epic denial of service attack issues on their verifier design, where code of specific forms leads to quadratic verification time.

cwzwarich 7y ago
There are a few different performance issues with the Java bytecode verifier. Are you referring to this one? https://pdfs.semanticscholar.org/7dd2/b5359ab507fec1b1223db6edf5f58f9a28b6.pdf https://pdfs.semanticscholar.org/7dd2/b5359ab507fec1b1223db6... The cause of this is that the dataflow analysis performs nontrivial merging of dataflow facts, requiring a reanalysis. In the WebAssembly design there is no merging; any divergence of stack effects is an error. There are other deeper issues with the Java design: bytecode subroutines, the fact that the Java subtype relation doesn't form a semilattice, and way in which Java bytecode models object initialization.

ghusbands 7y ago

I have an interest in this - can you point at the earlier, superior research, please?