4 ms·

Can you back that up? Modern JVM bytecode is cheap to verify and gives you very strong properties like memory and type safety, i.e. the app will not have buffe

Can you back that up? Modern JVM bytecode is cheap to verify and gives you very strong properties like memory and type safety, i.e. the app will not have buffer overflows or type confusion attacks in it. WASM gives you virtually no guarantees about the software running in it, beyond that it (maybe) can't escape its sandbox. It's a much better universal bytecode than any other offerings currently available. I think that's a very strong statement for something so debatable. WASM appears, to me eyes, to have numerous serious flaws that make me wonder why people are so excited about it. JVM bytecode appears to beat it in every aspect. 1. No GC support, no real workable plan to get there because there's also no type system worth a damn. They've been looking at it for years and this article says all they've got is a tiny stepping stone - no actual GC, just a way to mark pointers to things that came from JS in the type system. This wouldn't matter if the future of the web was software written in C, but if it is, god help us all. 2. No threading. JVM has been thread safe from the start, and has had a huge amount of work put into its memory model, so you can reason about the nature of bytecode when run on different CPUs and in the presence of multi-threading. Moreover making a runtime like V8 fast is much harder if you try to make it thread safe. JVMs have a long history of being fast in the presence of large scale threading but no WASM supporting VMs do. 3. No support for exceptions, apparently at least one failed attempt to add it. Even LLVM has support for exceptions. Again, no big deal if the future of the web is C99 but what a bad joke if it is. 4. No FFI of any use. 5. No dynamic code loading. 6. Tooling is poor or non-existent. 7. Ignoring these differences, WASM bytecode looks a lot like JVM bytecode e.g. is a stack based language that requires compilation client side via JITC to approach good performance. As far as I can tell it's a significant regression from what Java could do even 20 years ago. And don't start talking about security. WASM integrations already opened up critical security bugs in browsers: https://bugs.chromium.org/p/chromium/issues/detail?id=729991 https://bugs.chromium.org/p/chromium/issues/detail?id=729991 https://bugs.chromium.org/p/chromium/issues/detail?id=794091 https://bugs.chromium.org/p/chromium/issues/detail?id=794091 https://news.ycombinator.com/item?id=15712270 https://news.ycombinator.com/item?id=15712270 If you think WASM is magically immune to sandbox bugs, you're wrong.

naasking 8y ago
> WASM appears, to me eyes, to have numerous serious flaws that make me wonder why people are so excited about it. The reason to be excited about it is to have a universal sandbox to portably run untrusted code regardless of the source. That's unprecedented flexibility for something so widely deployed. Neither the JVM or the CLR provide such a sandbox for code that uses pointers. LLVM IR is not portable, is not sandboxed and is always in flux. As for your list of "flaws", they aren't flaws at all. A flaw is a feature that cannot be supported, even in principle. Everything you list are possible as extensions to the core type system. WASM was designed with efficient verification in mind, and with mechanized formal proofs as I point out at [1]. Java's verification was always a hack, and the mechanized proofs of Java's verification procedure never encompassed all JVM bytecodes, and full verification was always too costly to perform at runtime. Java has numerous security problems, not just with verification, but also vulnerabilities due to full abstraction failures. As I mentioned in [1], the security-focused Joe-E language explicitly chose to decompile JVM bytecode to plain Java to avoid all of the numerous documented full abstraction failures of the JVM [2]. The similarities between the stack-oriented bytecodes are entirely superficial. [1] https://news.ycombinator.com/item?id=17575111 https://news.ycombinator.com/item?id=17575111 [2] http://lambda-the-ultimate.org/node/3830 http://lambda-the-ultimate.org/node/3830
- repolfx 8y ago
  Neither the JVM or the CLR provide such a sandbox for code that uses pointers. LLVM IR is not portable, is not sandboxed and is always in flux. Actually, the CLR supports pointers and the JVM can run arbitrary LLVM bitcode (so C, C++, Rust etc) in a memory safe way with bounds checking and garbage collection these days. Check out Sulong and Safe Sulong: http://ssw.jku.at/General/Staff/ManuelRigger/ASPLOS18.pdf http://ssw.jku.at/General/Staff/ManuelRigger/ASPLOS18.pdf JVMs can also manually allocate memory using the Unsafe class, I suppose if you wanted WASM like protection semantics that API could be constrained to a particular memory region and become "SortaUnsafe" for example. You could then compile C to such a dialect. The LLVM bitcode on Graal approach is likely to work better though,. However, realistically most new software is not being written in C or even C++ for that matter. Most developers use managed languages. And the JVM can do a much better job of that than WASM can. A flaw is a feature that cannot be supported, even in principle. This is a fascinating definition of flaw that I haven't previously encountered. In what sense does the JVM not do "full verification at runtime"? Also if you have some more material on which bits of the JVM bytecode set aren't formally verified I'd like to read that. I can imagine, that the latest features may not have been done, but the older JVM bytecode sets were formally verified at least.

naasking 8y ago

> WASM appears, to me eyes, to have numerous serious flaws that make me wonder why people are so excited about it. The reason to be excited about it is to have a universal sandbox to portably run untrusted code regardless of the source. That's unprecedented flexibility for something so widely deployed. Neither the JVM or the CLR provide such a sandbox for code that uses pointers. LLVM IR is not portable, is not sandboxed and is always in flux. As for your list of "flaws", they aren't flaws at all. A flaw is a feature that cannot be supported, even in principle. Everything you list are possible as extensions to the core type system. WASM was designed with efficient verification in mind, and with mechanized formal proofs as I point out at [1]. Java's verification was always a hack, and the mechanized proofs of Java's verification procedure never encompassed all JVM bytecodes, and full verification was always too costly to perform at runtime. Java has numerous security problems, not just with verification, but also vulnerabilities due to full abstraction failures. As I mentioned in [1], the security-focused Joe-E language explicitly chose to decompile JVM bytecode to plain Java to avoid all of the numerous documented full abstraction failures of the JVM [2]. The similarities between the stack-oriented bytecodes are entirely superficial. [1] https://news.ycombinator.com/item?id=17575111 https://news.ycombinator.com/item?id=17575111 [2] http://lambda-the-ultimate.org/node/3830 http://lambda-the-ultimate.org/node/3830

repolfx 8y ago
Neither the JVM or the CLR provide such a sandbox for code that uses pointers. LLVM IR is not portable, is not sandboxed and is always in flux. Actually, the CLR supports pointers and the JVM can run arbitrary LLVM bitcode (so C, C++, Rust etc) in a memory safe way with bounds checking and garbage collection these days. Check out Sulong and Safe Sulong: http://ssw.jku.at/General/Staff/ManuelRigger/ASPLOS18.pdf http://ssw.jku.at/General/Staff/ManuelRigger/ASPLOS18.pdf JVMs can also manually allocate memory using the Unsafe class, I suppose if you wanted WASM like protection semantics that API could be constrained to a particular memory region and become "SortaUnsafe" for example. You could then compile C to such a dialect. The LLVM bitcode on Graal approach is likely to work better though,. However, realistically most new software is not being written in C or even C++ for that matter. Most developers use managed languages. And the JVM can do a much better job of that than WASM can. A flaw is a feature that cannot be supported, even in principle. This is a fascinating definition of flaw that I haven't previously encountered. In what sense does the JVM not do "full verification at runtime"? Also if you have some more material on which bits of the JVM bytecode set aren't formally verified I'd like to read that. I can imagine, that the latest features may not have been done, but the older JVM bytecode sets were formally verified at least.