3 ms·

The JVM can't really be properly sandboxed, though. Even the JDK developers have stopped trying and deprecated SecurityManager. On the other hand, WASM is speci

The JVM can't really be properly sandboxed, though. Even the JDK developers have stopped trying and deprecated SecurityManager. On the other hand, WASM is specifically designed to not really be able to do anything fancy unless you give it functions that actually do something externally. Besides, how would you even properly run C code on the JVM?

kaba0 3y ago
> The JVM can't really be properly sandboxed What happened is that people realized that blacklisting does not work. Whitelisting is the correct approach. There is absolutely zero reason why WASM would be better for that over the JVM — the JVM spec in itself has no visible side effect, not even printing, so it can’t do anything nefarious (besides cpu vulnerabilities, but that also apply to WASM). And you would run C code in a completely trivial way: you have a huge array which is your memory, and you read/write bytes to it.
- basique 3y ago
  > Whitelisting is the correct approach. Isn't most of the point of using the JVM thrown out if you have a limited standard library? > And you would run C code in a completely trivial way: you have a huge array which is your memory, and you read/write bytes to it. That sounds like it would have terrible performance. Would every read of an int have to manually build it from the 4 bytes it's made of? This just seems like something the JVM won't handle that well. Besides, this would mean that if you want to run a language like C#, which has references and value types (and you can make a reference to a value type from a pointer into a buffer), you would have to emulate them, which will hamper performance, or just use the same strategy as you used for C.
  - kaba0 3y ago
    > That sounds like it would have terrible performance. Would every read of an int have to manually build it from the 4 bytes it's made of? No, a method can have a native implementation, or a compiler intrinsic. Java has ByteBuffers (https://download.java.net/java/early_access/panama/docs/api/java.base/java/nio/ByteBuffer.html https://download.java.net/java/early_access/panama/docs/api/... ), and they have put/get{Long,Short,etc}, that will map to either a native single pointer read with the given size, or even optimize to a more efficient read inside the context of a bigger method, say vectorize them inside a loop (as the compiler knows about this method and can handle it specifically). > Besides, this would mean that if you want to run a language like C#, which has references and value types (and you can make a reference to a value type from a pointer into a buffer), you would have to emulate them, which will hamper performance, or just use the same strategy as you used for C So we are back at where WASM is? Though I think that there is nothing inherently impossible about mapping C# to more efficient Java primitives, especially that value types are the more constrained semantics, each instance being different is semantically the same, just less optimal. A pointer to a region of the aforementioned ByteBuffer with a special memoryToCSharpObject() that has some compiler intrinsics wouldn't perform too bad, I believe.
    - josephg 3y ago
      > So we are back at where WASM is? Exactly. By the time you've done all that, whats the point? You'll have reimplemented wasm on top of the jvm in a way that: - Can't use any of the java standard library (which all existing java code depends on) - So you also can't use any existing java code - You need a compilation step for any existing code in other languages to convert it into your special limited java syntax - And the result will run slower than wasm because of the extra layer of abstraction going on The one advantage is that you can output everything as standard .class files, so it'll be easier to pull this code into an existing java application. And yes, you could absolutely do that if you want and you see value in it. Heck - maybe it'd be nice to have a wasm-to-java-class converter to let you reuse all the wasm infrastructure. But this all sounds like the java equivalent to asmjs, which we already tried. Asmjs was the precursor to wasm. It was built on top of javascript primitives in much the same way as the proposal here builds on top of java primitives. As I understand it, the reason we ended up with wasm instead of asmjs was that: - Wasm was easier to optimize, had a smaller file size and was faster to load at runtime (since you don't need a javascript compiler) - Its much easier to make VMs for wasm in lots of languages and environments. Wasm modules can be loaded into programs written in python, rust, C, java, go, javascript, etc without some weird unnecessary dependency on javascript.
      - kaba0 3y ago
        > Can't use any of the java standard library (which all existing java code depends on) One can surely cherry-pick quite a lot out of it that are safe to use, e.g. anything not using `native` implementation can as per the former definition of JVM interpreter, also end up being safe. So many existing code would run without any change. > Re: compilation step Why? It has nothing to do with Java, the language, only the JVM class file format. Scala/Kotlin produce bytecode directly, not Java code. > Run slower Why would it? Wasm can run fast having grown out from asm.js, yet a JITted runtime that runs half of the internet can't? > Its much easier to make VMs for wasm in lots of languages and environments There are plenty toy JVMs out there as well, the core really is not difficult. And the point of all this would be that large chunks of the JVM could have been reused, that runs on every platform with top notch performance already, without all the growing pains that WASM will experience. Also, the JVM's type safe cross-language capabilities are already here, while they are very experimental and rudimentary in case of WASM. I can just call a Kotlin class from Clojure, or JPython or whatever, and vice versa.

kaba0 3y ago

> The JVM can't really be properly sandboxed What happened is that people realized that blacklisting does not work. Whitelisting is the correct approach. There is absolutely zero reason why WASM would be better for that over the JVM — the JVM spec in itself has no visible side effect, not even printing, so it can’t do anything nefarious (besides cpu vulnerabilities, but that also apply to WASM). And you would run C code in a completely trivial way: you have a huge array which is your memory, and you read/write bytes to it.

basique 3y ago
> Whitelisting is the correct approach. Isn't most of the point of using the JVM thrown out if you have a limited standard library? > And you would run C code in a completely trivial way: you have a huge array which is your memory, and you read/write bytes to it. That sounds like it would have terrible performance. Would every read of an int have to manually build it from the 4 bytes it's made of? This just seems like something the JVM won't handle that well. Besides, this would mean that if you want to run a language like C#, which has references and value types (and you can make a reference to a value type from a pointer into a buffer), you would have to emulate them, which will hamper performance, or just use the same strategy as you used for C.
- kaba0 3y ago
  > That sounds like it would have terrible performance. Would every read of an int have to manually build it from the 4 bytes it's made of? No, a method can have a native implementation, or a compiler intrinsic. Java has ByteBuffers (https://download.java.net/java/early_access/panama/docs/api/java.base/java/nio/ByteBuffer.html https://download.java.net/java/early_access/panama/docs/api/... ), and they have put/get{Long,Short,etc}, that will map to either a native single pointer read with the given size, or even optimize to a more efficient read inside the context of a bigger method, say vectorize them inside a loop (as the compiler knows about this method and can handle it specifically). > Besides, this would mean that if you want to run a language like C#, which has references and value types (and you can make a reference to a value type from a pointer into a buffer), you would have to emulate them, which will hamper performance, or just use the same strategy as you used for C So we are back at where WASM is? Though I think that there is nothing inherently impossible about mapping C# to more efficient Java primitives, especially that value types are the more constrained semantics, each instance being different is semantically the same, just less optimal. A pointer to a region of the aforementioned ByteBuffer with a special memoryToCSharpObject() that has some compiler intrinsics wouldn't perform too bad, I believe.
  - josephg 3y ago
    > So we are back at where WASM is? Exactly. By the time you've done all that, whats the point? You'll have reimplemented wasm on top of the jvm in a way that: - Can't use any of the java standard library (which all existing java code depends on) - So you also can't use any existing java code - You need a compilation step for any existing code in other languages to convert it into your special limited java syntax - And the result will run slower than wasm because of the extra layer of abstraction going on The one advantage is that you can output everything as standard .class files, so it'll be easier to pull this code into an existing java application. And yes, you could absolutely do that if you want and you see value in it. Heck - maybe it'd be nice to have a wasm-to-java-class converter to let you reuse all the wasm infrastructure. But this all sounds like the java equivalent to asmjs, which we already tried. Asmjs was the precursor to wasm. It was built on top of javascript primitives in much the same way as the proposal here builds on top of java primitives. As I understand it, the reason we ended up with wasm instead of asmjs was that: - Wasm was easier to optimize, had a smaller file size and was faster to load at runtime (since you don't need a javascript compiler) - Its much easier to make VMs for wasm in lots of languages and environments. Wasm modules can be loaded into programs written in python, rust, C, java, go, javascript, etc without some weird unnecessary dependency on javascript.
    - kaba0 3y ago
      > Can't use any of the java standard library (which all existing java code depends on) One can surely cherry-pick quite a lot out of it that are safe to use, e.g. anything not using `native` implementation can as per the former definition of JVM interpreter, also end up being safe. So many existing code would run without any change. > Re: compilation step Why? It has nothing to do with Java, the language, only the JVM class file format. Scala/Kotlin produce bytecode directly, not Java code. > Run slower Why would it? Wasm can run fast having grown out from asm.js, yet a JITted runtime that runs half of the internet can't? > Its much easier to make VMs for wasm in lots of languages and environments There are plenty toy JVMs out there as well, the core really is not difficult. And the point of all this would be that large chunks of the JVM could have been reused, that runs on every platform with top notch performance already, without all the growing pains that WASM will experience. Also, the JVM's type safe cross-language capabilities are already here, while they are very experimental and rudimentary in case of WASM. I can just call a Kotlin class from Clojure, or JPython or whatever, and vice versa.