4 ms·

Uhh, how is it polyglot if it only accepts one language (Java)?

neilalexander 5y ago
It accepts Java bytecode, but various programming languages (Java, Kotlin, Scala, Clojure to name a few) are built on top of that.
dkersten 5y ago
Java, Kotlin, Clojure, Scala, Groovy More here: https://en.wikipedia.org/wiki/List_of_JVM_languages https://en.wikipedia.org/wiki/List_of_JVM_languages It accepts any language that compiles to JVM bytecode. Java is just one of them. Just like an x86 processor accepts any language that compiles to x86 instructions.
- linkpuff 5y ago
  Doesn't that require a language to be engineered to output java bytecode? For example, rust can't be compiled to java bytecode because it does things that jvm can't do. A real polyglot can't only understand a language by requiring it to speak its native language Wasm supports languages that weren't created with wasm in mind, just by requiring a compiler with the right output, without restraining the language.
  - still_grokking 5y ago
    Of course you could run Rust on the JVM (more precisely on GraalVM)! Have a look at Project Sulong. https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong
    - sitkack 5y ago
      GraalVM has a Wasm front end, there is almost no reason to use bitcode as the interface to Graal. https://www.graalvm.org/reference-manual/wasm/ https://www.graalvm.org/reference-manual/wasm/
      - still_grokking 5y ago
        That makes no sense in case of Rust (or C/C++ for that matter). You would compile LLVM-frontend -> LLVM-IR -> LLVM-WASM-backend -> GraalVM-WASM-frontend -> GraalVM-bytecode-backend instead of LLVM-frontend -> LLVM-IR -> GraalVM-LLVM-IR-frontend -> GraalVM-bytecode-backend The additional transformations won't be healthy for the performance of your program, or compile times…
        sitkack 5y ago
        Does the second compilation chain do Control Flow Integrity? https://en.wikipedia.org/wiki/Control-flow_integrity https://en.wikipedia.org/wiki/Control-flow_integrity https://clang.llvm.org/docs/ControlFlowIntegrity.html https://clang.llvm.org/docs/ControlFlowIntegrity.html It looks like it might be possible, but I really like the security properties of Wasm. It looks like I am moving the goal posts, but I am not, it is the biggest reason to use Wasm, the second one is the capabilities model. It would be a great undergrad research project to measure the difference in those two compilation chains.
        still_grokking 5y ago
        I'm not sure you could hack the control flow when running bytecode on the JVM, but I strongly doubt that. (The JVM is "high-level" as pointed out previously and doesn't execute ASM like code. So there is no of the attack surface you have to care on the ASM level). And capabilities are anyway something that belongs into the OS — and than programs need to be written accordingly. The whole point of the capability-security model is that you can't add it after the fact. That's why UNIX isn't, and never will be, a capability secure OS. But "sanboxing" some process running on a VM is completely independent of that! WASM won't get you anything beyond a "simple sanbox" ootb. Exactly the same as you have in the other major VM runtimes. If you want capability-secure Rust, there is much more to that. You have to change a lot of code, and use an alternative std. lib¹. Of course you can't than use any code (or OS functionality) if it isn't also capability-secure. Otherwise the model breaks. To be capability-secure you have actually to rewrite the world… ¹ https://github.com/bytecodealliance/cap-std https://github.com/bytecodealliance/cap-std
  - dkersten 5y ago
    > just by requiring a compiler with the right output, How is that different from a compiler that generates JVM bytecode? Yes, the bytecode was designed specifically for Java's needs, but running languages that weren't designed for the JVM on the JVM is still less of a stretch than compiling C to asm.js, something which has worked quite successfully. Or targeting a different CPU architecture.
deleted 5y ago
[deleted]

It accepts Java bytecode, but various programming languages (Java, Kotlin, Scala, Clojure to name a few) are built on top of that.

dkersten 5y ago

Java, Kotlin, Clojure, Scala, Groovy More here: https://en.wikipedia.org/wiki/List_of_JVM_languages https://en.wikipedia.org/wiki/List_of_JVM_languages It accepts any language that compiles to JVM bytecode. Java is just one of them. Just like an x86 processor accepts any language that compiles to x86 instructions.

linkpuff 5y ago
Doesn't that require a language to be engineered to output java bytecode? For example, rust can't be compiled to java bytecode because it does things that jvm can't do. A real polyglot can't only understand a language by requiring it to speak its native language Wasm supports languages that weren't created with wasm in mind, just by requiring a compiler with the right output, without restraining the language.
- still_grokking 5y ago
  Of course you could run Rust on the JVM (more precisely on GraalVM)! Have a look at Project Sulong. https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong
  - sitkack 5y ago
    GraalVM has a Wasm front end, there is almost no reason to use bitcode as the interface to Graal. https://www.graalvm.org/reference-manual/wasm/ https://www.graalvm.org/reference-manual/wasm/
    - still_grokking 5y ago
      That makes no sense in case of Rust (or C/C++ for that matter). You would compile LLVM-frontend -> LLVM-IR -> LLVM-WASM-backend -> GraalVM-WASM-frontend -> GraalVM-bytecode-backend instead of LLVM-frontend -> LLVM-IR -> GraalVM-LLVM-IR-frontend -> GraalVM-bytecode-backend The additional transformations won't be healthy for the performance of your program, or compile times…
      - sitkack 5y ago
        Does the second compilation chain do Control Flow Integrity? https://en.wikipedia.org/wiki/Control-flow_integrity https://en.wikipedia.org/wiki/Control-flow_integrity https://clang.llvm.org/docs/ControlFlowIntegrity.html https://clang.llvm.org/docs/ControlFlowIntegrity.html It looks like it might be possible, but I really like the security properties of Wasm. It looks like I am moving the goal posts, but I am not, it is the biggest reason to use Wasm, the second one is the capabilities model. It would be a great undergrad research project to measure the difference in those two compilation chains.
        still_grokking 5y ago
        I'm not sure you could hack the control flow when running bytecode on the JVM, but I strongly doubt that. (The JVM is "high-level" as pointed out previously and doesn't execute ASM like code. So there is no of the attack surface you have to care on the ASM level). And capabilities are anyway something that belongs into the OS — and than programs need to be written accordingly. The whole point of the capability-security model is that you can't add it after the fact. That's why UNIX isn't, and never will be, a capability secure OS. But "sanboxing" some process running on a VM is completely independent of that! WASM won't get you anything beyond a "simple sanbox" ootb. Exactly the same as you have in the other major VM runtimes. If you want capability-secure Rust, there is much more to that. You have to change a lot of code, and use an alternative std. lib¹. Of course you can't than use any code (or OS functionality) if it isn't also capability-secure. Otherwise the model breaks. To be capability-secure you have actually to rewrite the world… ¹ https://github.com/bytecodealliance/cap-std https://github.com/bytecodealliance/cap-std
- dkersten 5y ago
  > just by requiring a compiler with the right output, How is that different from a compiler that generates JVM bytecode? Yes, the bytecode was designed specifically for Java's needs, but running languages that weren't designed for the JVM on the JVM is still less of a stretch than compiling C to asm.js, something which has worked quite successfully. Or targeting a different CPU architecture.

deleted 5y ago

[deleted]