Understanding abstractions in WASI and JVM

[proohit]

I have a general question of understanding WASM and WASI in comparison to JVM. My question is if the JVM actually provides a virtual operating system too, similar to how WASI does.

As for my understanding, WASM and JVM are both virtual machines, providing an environment to compile/execute/interpret (you name it) some bytecode. Their aim is to abstract the machine layer, thus CPU (architecture) and its' ISA.

WASM itself has no access to other system resources (fs, networking, ...) because of it's sandbox design. It can only talk to the CPU and Memory. That's where WASI, as an extension to WASM, provides an abstract operating system layer, so that system resources can be accessed.

For Java applications, I can use native (e.g. Java std lib) APIs, such as java.io/java.nio or java.net, directly on the JVM.

I understand that both approaches handle security differently. E.g. I do not need to provide access to a file myself to a Java application, but as with WASI I do need to. My question is rather if they conceptually provide similar levels of abstractions in case of the OS and the underlying physical machines.

Thanks in advance!

PS: Yes, I've asked this question on Stackoverflow but unfortunately, I'm still left a little confused and would be happy about an answer literally from the source :).

[sbc100]

I think your understanding fairly accurate. WebAssembly itself does not define any APIs at all and so it more clearly just a VM. It requires a separate standard such as WASI (or the emscripten APIs on the Web) to actually interact with the outside world.

Because of this, different WebAssembly APIs can decide how they want to expose the OS functionality. With WASI, one of the primary goals is componentization and capability-based security module. The emscripten system API, on the other hand, exposes access the the Web APIs and doesn't try to add any extra security guarantees on top of what the web already provides.

So, in part because WebAssembly itself does not dictate the API landscape, it allows for multiple different APIs to expose OS capabilities is very different ways.

IIUC the Java world is not quite a well compartmentalized with certain APIs being defined (or at least, in practice, assumed to exist) as part of the VM itself.

[proohit]

Thank you very much for clarifying WASM capabilities.

So just for my understanding: Almost any use case can be implemented with WASM, provided a (custom) set of APIs with needed functionality by the underlying runtime. WASI declares a standardized set of APIs, which can be looked up as reference and implemented in runtimes. The core of WASI is to be standardized. As you mentioned, JVM does define a VM with a subset of OS functions. However, it does not draw a strict line between being a (virtual) machine and a (virtual) OS.

Are those statements kinda correct? If yes, then I think I was able to loosen my confusion, thanks to you :).

[sbc100]

Your understanding sounds correct to me.

[proohit]

Perfect, thanks!

I'm reading through "Virtualization Essentials" by Matthew Portnoy currently, and he defines a virtual machine with the property to provide an operating system to be a machine as a "whole". I know this is just a definition, but now I'm wondering, what are the benefits of separating the virtual machine (WASM) and it's OS (WASI) as a design choice? Is there anything you considered and learned from JVM and Java, since they provide more a VM as a "whole"?

[sbc100]

There are many advantages to separating the concerns of computation from the concerns of OS interaction. For WebAssembly in particular one of the primary reasons not to consider OS interaction as core is that it was designed primarily/initially with the Web in mind, and when running on the web there is no a traditional OS to interact with. For example, there is no filesystem access on the Web.

Of course, simply reducing the scope of WebAssembly keeps it simpler, more focused, and more portable as a core technology. That alone is huge benefit.

[sunfishcode]

The original question here appears answered; please reopen or file a new issue if there are any further questions!