7 ms·

While it’s true that it somewhat locks you into a single VM type (WASM), that’s very different from being locked into the JVM. For one, the idea is that it sho

by orf 4y ago

While it’s true that it somewhat locks you into a single VM type (WASM), that’s very different from being locked into the JVM. For one, the idea is that it should be fairly simple to compile an arbitrary program to WASM, allowing you to use a far wider variety of languages. In this case, it’s more akin to “docker with extra steps” as opposed to “docker but you can only hire Java devs”

pjmlp 4y ago
Well, http://nestedvm.ibex.org/ http://nestedvm.ibex.org/
- orf 4y ago
  If the best counterpoint I could find is a dead proof of concept project from over a decade ago that only works on an unsupported compiler released 17 years ago, I would reevaluate my position
  - pjmlp 4y ago
    Unfortunately it lacked the buzzwords of VC money to make it a trendy topic.
- sitkack 4y ago
  You realize nestedvm is compiling native code to MIPS and then inlining the MIPS interpreter into the generated class files? Had the JVM supported unsigned types, none of this would have been necessary. Wasm is a refinement of the ideas in the JVM, with a couple good JVM on Wasm solutions already existing. The best of which is CheerpJ. Instead of referencing NestedVM, you should link to GraalVM which I know you are aware of.
  - layer8 4y ago
    Unsigned types are trivially emulated using signed types. All arithmetic operations except division/remainder and comparison are identical on the bit level, and the latter are supported via `Long.divideUnsigned()` and friends, which can JIT to the native unsigned operations of the underlying platform. The main difference with regard to compiling “arbitrary” programs between the JVM and WASM is that the JVM doesn’t have untyped linear memory like WASM does. WASM isn’t type-safe within the linear-memory regions (which is what allows C-like languages to be compiled more directly), whereas JVM ensures type safety for all objects. Saying that “WASM is a refinement of the ideas in the JVM” is simply wrong, they have different design goals and therefore implement different design trade-offs.
    - sitkack 4y ago
      > JVM and WASM [sic] is that the JVM doesn’t have untyped linear memory like WASM does. As you say, it can be trivially emulated, no reason that linear memory couldn't be implemented on the JVM using an array of primitive (char,int,long). The Wasm VM is more generic and has a better capabilities security model than the JVM. Had the JVM been more like Wasm (signed and unsigned primitives, capabilities model), it would have been a natural compilation target for sandboxing native code. As Wasm gets more features it becomes more like the JVM (GC, reference types, component model). Eventually Wasm will subsume all the features that differentiates them.
treis 4y ago
>single VM type (WASM), that’s very different from being locked into the JVM. Why is that different?
- orf 4y ago
  You can’t run Postgres on the JVM. WASM is pretty different to the JVM. The JVM deals with a lot of higher level constructs like objects, constructors, virtual methods, the GC etc. Which is fine if the language you’re hosting works in that way. WASM is more like assembly - the raw intrinsics used by a hypothetical WASM CPU. So you can compile a lot more stuff to it, because it’s a more natural target than a much, much higher level VM like the JVM.
  - treis 4y ago
    But there's not much point to running Postgres in WASM. It's written in C to avoid the performance overhead of a VM in the first place.
  - mike_hearn 4y ago
    Although that's true (ish... you can run WASM on the JVM now, and also LLVM bitcode), that takes you into the realm of why you'd want to. On the browser side, you could maybe make a ChromeOS style argument of just wanting to run everything in a browser no matter what, it's nice for it to be sandboxed etc. But if you look at what your Postgres is doing it's sort of a Linux VM, and you can run those already at full speed: that's WSL and there are various solutions on macOS like Docker Desktop. On the server side, the reason nobody bothered trying to run Postgres on the JVM before Graal is that it's unclear what the benefit is. Security? Processes and kernel isolation seems to work well enough on the server, and anyway Postgres is a highly trusted component anyway. CPU independence? That hasn't been useful since stuff like SPARC died, we are now just starting to see ARM chips appear on the server, but compiling native code for both intel and arm isn't hard and Linux distros have the infrastructure to do it for a long time already. For custom servers, well, not many are writing them in C/C++/Rust anyway these days. RISC-V remains mostly theoretical. To what extent is this doing it because it can be done, vs delivering real benefits? My mind is open but the low level nature of the WASM instruction set also means the VM can't offer many benefits to the programs inside it, nor the users outside it.
mike_hearn 4y ago
Can you actually compile an arbitrary program to WASM? I thought they had to be ported to WASI first and can't use any operating system APIs. Otherwise, how can it be sandboxed? Arbitrary programs can call into arbitrary OS-native APIs and execute arbitrary native code outside the bounds of the WASM VM, including things like JITing native code.
- orf 4y ago
  It depends on the program being compiled, but yes you can. You can run Postgres using WASM in two different ways[1][2]. That’s a non-trivial codebase. 1. https://www.crunchydata.com/blog/learn-postgres-at-the-playground https://www.crunchydata.com/blog/learn-postgres-at-the-playg... 2. https://supabase.com/blog/postgres-wasm https://supabase.com/blog/postgres-wasm
  - mike_hearn 4y ago
    That works by compiling some sort of Linux VM into WASM as well, which isn't arbitrary programs (that would have to include Windows and macOS programs too).
    - orf 4y ago
      I feel like you’re nitpicking and ignoring the actual argument you originally made? You can compile arbitrary programs to WASM, like you can compile arbitrary programs to x86 or ARM. It’s effectively a CPU target. You can take the whole of Python and SQLite, compile them to WASM and run a web framework on top of that via WASM in the browser[1]. If those programs utilise specific os-level behaviour that can’t be shimmed, or explicitly throw an error when being compiled to WASM then of course they won’t work without modifications. Meanwhile, the JVM is not anything like a CPU target. It’s a very high-level VM designed for a particular type of gc’d and jitted language. 1. https://simonwillison.net/2022/May/4/datasette-lite/ https://simonwillison.net/2022/May/4/datasette-lite/
pbecotte 4y ago
I don't think the statement "fairly simple to compile an arbitrary program" hasn't been true for any ecosystem, ever.
kaba0 4y ago
Making a big byte array and using some very basic jvm instructions will give you a very low-level compilation target for basically any language.

by orf 4y ago

pjmlp 4y ago

Well, http://nestedvm.ibex.org/ http://nestedvm.ibex.org/

orf 4y ago
If the best counterpoint I could find is a dead proof of concept project from over a decade ago that only works on an unsupported compiler released 17 years ago, I would reevaluate my position
- pjmlp 4y ago
  Unfortunately it lacked the buzzwords of VC money to make it a trendy topic.
sitkack 4y ago
You realize nestedvm is compiling native code to MIPS and then inlining the MIPS interpreter into the generated class files? Had the JVM supported unsigned types, none of this would have been necessary. Wasm is a refinement of the ideas in the JVM, with a couple good JVM on Wasm solutions already existing. The best of which is CheerpJ. Instead of referencing NestedVM, you should link to GraalVM which I know you are aware of.
- layer8 4y ago
  Unsigned types are trivially emulated using signed types. All arithmetic operations except division/remainder and comparison are identical on the bit level, and the latter are supported via `Long.divideUnsigned()` and friends, which can JIT to the native unsigned operations of the underlying platform. The main difference with regard to compiling “arbitrary” programs between the JVM and WASM is that the JVM doesn’t have untyped linear memory like WASM does. WASM isn’t type-safe within the linear-memory regions (which is what allows C-like languages to be compiled more directly), whereas JVM ensures type safety for all objects. Saying that “WASM is a refinement of the ideas in the JVM” is simply wrong, they have different design goals and therefore implement different design trade-offs.
  - sitkack 4y ago
    > JVM and WASM [sic] is that the JVM doesn’t have untyped linear memory like WASM does. As you say, it can be trivially emulated, no reason that linear memory couldn't be implemented on the JVM using an array of primitive (char,int,long). The Wasm VM is more generic and has a better capabilities security model than the JVM. Had the JVM been more like Wasm (signed and unsigned primitives, capabilities model), it would have been a natural compilation target for sandboxing native code. As Wasm gets more features it becomes more like the JVM (GC, reference types, component model). Eventually Wasm will subsume all the features that differentiates them.

treis 4y ago

>single VM type (WASM), that’s very different from being locked into the JVM. Why is that different?

orf 4y ago
You can’t run Postgres on the JVM. WASM is pretty different to the JVM. The JVM deals with a lot of higher level constructs like objects, constructors, virtual methods, the GC etc. Which is fine if the language you’re hosting works in that way. WASM is more like assembly - the raw intrinsics used by a hypothetical WASM CPU. So you can compile a lot more stuff to it, because it’s a more natural target than a much, much higher level VM like the JVM.
- treis 4y ago
  But there's not much point to running Postgres in WASM. It's written in C to avoid the performance overhead of a VM in the first place.
- mike_hearn 4y ago
  Although that's true (ish... you can run WASM on the JVM now, and also LLVM bitcode), that takes you into the realm of why you'd want to. On the browser side, you could maybe make a ChromeOS style argument of just wanting to run everything in a browser no matter what, it's nice for it to be sandboxed etc. But if you look at what your Postgres is doing it's sort of a Linux VM, and you can run those already at full speed: that's WSL and there are various solutions on macOS like Docker Desktop. On the server side, the reason nobody bothered trying to run Postgres on the JVM before Graal is that it's unclear what the benefit is. Security? Processes and kernel isolation seems to work well enough on the server, and anyway Postgres is a highly trusted component anyway. CPU independence? That hasn't been useful since stuff like SPARC died, we are now just starting to see ARM chips appear on the server, but compiling native code for both intel and arm isn't hard and Linux distros have the infrastructure to do it for a long time already. For custom servers, well, not many are writing them in C/C++/Rust anyway these days. RISC-V remains mostly theoretical. To what extent is this doing it because it can be done, vs delivering real benefits? My mind is open but the low level nature of the WASM instruction set also means the VM can't offer many benefits to the programs inside it, nor the users outside it.

mike_hearn 4y ago

Can you actually compile an arbitrary program to WASM? I thought they had to be ported to WASI first and can't use any operating system APIs. Otherwise, how can it be sandboxed? Arbitrary programs can call into arbitrary OS-native APIs and execute arbitrary native code outside the bounds of the WASM VM, including things like JITing native code.

orf 4y ago
It depends on the program being compiled, but yes you can. You can run Postgres using WASM in two different ways[1][2]. That’s a non-trivial codebase. 1. https://www.crunchydata.com/blog/learn-postgres-at-the-playground https://www.crunchydata.com/blog/learn-postgres-at-the-playg... 2. https://supabase.com/blog/postgres-wasm https://supabase.com/blog/postgres-wasm
- mike_hearn 4y ago
  That works by compiling some sort of Linux VM into WASM as well, which isn't arbitrary programs (that would have to include Windows and macOS programs too).
  - orf 4y ago
    I feel like you’re nitpicking and ignoring the actual argument you originally made? You can compile arbitrary programs to WASM, like you can compile arbitrary programs to x86 or ARM. It’s effectively a CPU target. You can take the whole of Python and SQLite, compile them to WASM and run a web framework on top of that via WASM in the browser[1]. If those programs utilise specific os-level behaviour that can’t be shimmed, or explicitly throw an error when being compiled to WASM then of course they won’t work without modifications. Meanwhile, the JVM is not anything like a CPU target. It’s a very high-level VM designed for a particular type of gc’d and jitted language. 1. https://simonwillison.net/2022/May/4/datasette-lite/ https://simonwillison.net/2022/May/4/datasette-lite/

pbecotte 4y ago

I don't think the statement "fairly simple to compile an arbitrary program" hasn't been true for any ecosystem, ever.

kaba0 4y ago

Making a big byte array and using some very basic jvm instructions will give you a very low-level compilation target for basically any language.