A big difference from [Wasm and the JVM], though, is that SaberVM's analysis includes memory safety, like Rust. For that, it uses regions (as well as Vale's system, which is a big inspiration).
What about the verification complexity? The JVM screwed this part up somewhat, from what I understand, while Wasm is carefully designed to be linear to parse and verify throughout. And complex type systems aren’t always trivial to even check types in.
The JVM doesn't try to guarantee memory safety
Wait, what? I always thought that (barring JNI and so on) Java bytecode was completely memory-safe (having been intended to run mutually suspicious code in the first place), it’s just that this is accomplished at the cost of pervasive tracing GC and bounds checks everywhere.
The type system is stolen from some of the work on TAL (typed assembly language), by Greg Morrisett and others. In my implementation at the moment it's linear first in the size of the program and then there's a little more checking that's linear in the number of functions. The design is still settling, and it very well might be just linear in the future.
Your point about garbage collection is very fair. For some reason in my head when I wrote that I thought of null pointer exceptions, but that is indeed a different thing.
Comments
What about the verification complexity? The JVM screwed this part up somewhat, from what I understand, while Wasm is carefully designed to be linear to parse and verify throughout. And complex type systems aren’t always trivial to even check types in.
Wait, what? I always thought that (barring JNI and so on) Java bytecode was completely memory-safe (having been intended to run mutually suspicious code in the first place), it’s just that this is accomplished at the cost of pervasive tracing GC and bounds checks everywhere.
The type system is stolen from some of the work on TAL (typed assembly language), by Greg Morrisett and others. In my implementation at the moment it's linear first in the size of the program and then there's a little more checking that's linear in the number of functions. The design is still settling, and it very well might be just linear in the future.
Your point about garbage collection is very fair. For some reason in my head when I wrote that I thought of null pointer exceptions, but that is indeed a different thing.