[Feature] Nanoprocess Architectural pattern

[jayadevanraja]

It will be really great if, similar to WASM, the Nanoprocess Architectural pattern can be supported in GraalVM. With nanoprocesses, we can have benefits of massively modular applications, possiblity to wrap each package into tiny little processes, cold start that is super-fast, making software more composable, etc. That is, ability to use microservices-style architecture and language interoperability, with a finer-grained approach to defining the component services.

[kaspernielsen]

I think you can come a long way just by using Isolates.

[jayadevanraja]

Are the strengths of GraalVM's isolates and Wasm's nanoprocesses complementary? If yes, there is great opportunity for synergy. It will be great if somebody can shed light on the differences between the two and also about the opportunities for utilizing both.

Can GraalVM and Wasm utilize the techniques (isolates and nanoprocesses) of each other?

[kaspernielsen]

What I like about Wasm is they are explicit about which resources a subprocess will have access to. As you explicitly have to passe a resource handle of some kind to the subprocess, delegating access. In Java we are slowly moving there, for example, with Lookup objects for delegation of access rights. However, there is no support for IO. Xtclang is another good example https://xtclang.blogspot.com/2019/04/on-god-turtles-balloons-and-sandboxes.html of that explicit delegation model is another good example.

I think we will see this model be very common in a couple of years. And I'm Loom will get some fe support for it at some point.

[jayadevanraja]

What about the possibility of some library/framework which can handle both VMs in a single process? That would prevent a lot of duplication of effort- Just a thought 😉.

Anyway, it will be helpful if somebody can make a detailed table of the differences between both.

[matneu]

GraalVM isolates are a feature specific to native image that enables running multiple independent VM instances in the same process. Their isolation is deeper down the stack than nanoprocesses, for example, they have their own, dedicated heap instances. This means that when it comes to sharing data, one would need to set up explicit communication channels at a level similar to what is required when two different OS processes want to communicate.

Nanoprocesses better compare to Truffle polyglot execution contexts. A Truffle context can be granted certain access rights to resources. For example, a Truffle context can be associated with a Truffle filesystem that only exposes a limited view on the host filesystem. Truffle contexts are created by the host application, which can also orchestrate data exchange between contexts.

For more information, please have a look at the reference documentation on the polyglot API and our security guide.

[jayadevanraja]

Thanks for the clarification.

So, perhaps this issue can be closed, concluding that Nanoprocess architectural pattern is already supported by GraalVM in the form of Truffle polyglot execution contexts.