GraalVM isolates working on OSv

[Waldek Kozaczuk]

With a couple of fairly trivial patches applied recently I finally got GraalVM isolates working properly on OSv. The GraalVM isolates seem to provide in-process isolation or some sort of "multi-tenant VM instances within the same app" experience and reduce memory utilization. For more details please:

• see this issue - https://github.com/cloudius-systems/osv/issues/1031 - where I have exchanged some info with one of the GraalVM committers,
• new OSv example - https://github.com/cloudius-systems/osv-apps/tree/master/graalvm-netty-plot and 
• this pretty detailed article about isolates implementation - https://medium.com/graalvm/isolates-and-compressed-references-more-flexible-and-efficient-memory-management-for-graalvm-a044cc50b67e

This somehow reminds me or makes it look similar to what OSv attempted to achieve with IsolatedJVM construct within run-java wrapper. It seems graalvm isolates are more sophisticated and provides much better isolation and memory management.

Could also anybody confirm if any/all 3 graalvm-* examples work on their distributions? Please, note that the produced apps are regular Linux executables that should run on both Linux and OSv as is.

[Nadav Har'El]

On Tue, Jul 9, 2019 at 7:33 AM Waldek Kozaczuk <jwkoz...@gmail.com> wrote:

With a couple of fairly trivial patches applied recently I finally got GraalVM isolates working properly on OSv. The GraalVM isolates seem to provide in-process isolation or some sort of "multi-tenant VM instances within the same app" experience and reduce memory utilization. For more details please:

• see this issue - https://github.com/cloudius-systems/osv/issues/1031 - where I have exchanged some info with one of the GraalVM committers,
• new OSv example - https://github.com/cloudius-systems/osv-apps/tree/master/graalvm-netty-plot and 
• this pretty detailed article about isolates implementation - https://medium.com/graalvm/isolates-and-compressed-references-more-flexible-and-efficient-memory-management-for-graalvm-a044cc50b67e

This somehow reminds me or makes it look similar to what OSv attempted to achieve with IsolatedJVM construct within run-java wrapper. It seems graalvm isolates are more sophisticated and provides much better isolation and memory management.

Interesting. I think one of the strong points of our own "Isolated" Java - which indeed wasn't very sophisticated and was mostly a facade around loader namespaces and a few other smaller features - was that it did *not* have memory management. The point wasn't to isolate different applications from the bugs of other applications, but rather to allow two applications - usually a "main" application and some "sidecar" (e.g., ssh server, log manager, etc.) - to run side by side, and it is better not to have to divide up any of the resources, including memory or CPUs or anything, between those two applications, and rather let this division happen naturally, as happens when two Java threads use resources. But the downside of our implementation was, of course, that it was a hack, and there were a lot of things which weren't really "isolated" or "virtualized" between our isolates.

Could also anybody confirm if any/all 3 graalvm-* examples work on their distributions? Please, note that the produced apps are regular Linux executables that should run on both Linux and OSv as is.

I tried apps/graalvm-netty-plot on my Fedora 29. I think it download a terabyte of stuff ;-) But it seems to work - I ran

scripts/run.py --forward tcp::8080-:8080 and set my browser to http::/localhost:8080, and saw some graph. And no error message or crash or anything bad. Nice.

--
You received this message because you are subscribed to the Google Groups "OSv Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/09b6717f-632c-4faf-8fc1-a3b72f40e7f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Waldek Kozaczuk]

On Tuesday, July 9, 2019 at 3:56:27 AM UTC-4, Nadav Har'El wrote:

On Tue, Jul 9, 2019 at 7:33 AM Waldek Kozaczuk <jwkoz...@gmail.com> wrote:

With a couple of fairly trivial patches applied recently I finally got GraalVM isolates working properly on OSv. The GraalVM isolates seem to provide in-process isolation or some sort of "multi-tenant VM instances within the same app" experience and reduce memory utilization. For more details please:

• see this issue - https://github.com/cloudius-systems/osv/issues/1031 - where I have exchanged some info with one of the GraalVM committers,
• new OSv example - https://github.com/cloudius-systems/osv-apps/tree/master/graalvm-netty-plot and 
• this pretty detailed article about isolates implementation - https://medium.com/graalvm/isolates-and-compressed-references-more-flexible-and-efficient-memory-management-for-graalvm-a044cc50b67e

This somehow reminds me or makes it look similar to what OSv attempted to achieve with IsolatedJVM construct within run-java wrapper. It seems graalvm isolates are more sophisticated and provides much better isolation and memory management.

Interesting. I think one of the strong points of our own "Isolated" Java - which indeed wasn't very sophisticated and was mostly a facade around loader namespaces and a few other smaller features - was that it did *not* have memory management. The point wasn't to isolate different applications from the bugs of other applications, but rather to allow two applications - usually a "main" application and some "sidecar" (e.g., ssh server, log manager, etc.) - to run side by side, and it is better not to have to divide up any of the resources, including memory or CPUs or anything, between those two applications, and rather let this division happen naturally, as happens when two Java threads use resources. But the downside of our implementation was, of course, that it was a hack, and there were a lot of things which weren't really "isolated" or "virtualized" between our isolates.

The isolates are only available to native images that run with embedded SubstrateVM - the simpler equivalent of the hotspot VM in a full-blown JVM. The key thing (to me) about memory management in isolates is the aspect of automated variables management that does NOT involve any garbage collector and seems to behave like auto variables in C/C++ but can span multiple levels of function invocations.

Any variables allocated between the calls createIsolate() and tearDownIsolate() (as shown below) gets automatically deallocated simply because memory gets un-mapped and no-expensive analysis is needed to determine what is garbage and what is not, because it is only used by single isolate:

/* Create a new isolate for the next function evaluation. */

IsolateThread newContext = Isolates.createIsolate(CreateIsolateParameters.getDefault());
....
....

/* Tear down the isolate, freeing all the temporary objects. */

Isolates.tearDownIsolate(newContext);

This makes memory de-allocation way faster and cheaper than on traditional JVM. So one way to take advantage of isolates is to split your Java, Scala, Kotlin app into parts that operate on independent memory segments. But in order to exchange data between isolates one requires explicit copy operation. 

Base on the paragraph "Isolate Implementation Details" in that article it looks the code segment of memory gets mmap-ped and mprotected for each isolate (kind of similar to OSv ELF namespaces, no?) and another segment of memory mmaped with copy-on-write semantics for the data. Any code access seems to be based on the "heap-register" for which they use the register R14 and that way they can also compress all references to code and data within single isolate by using 32-bit only addresses.

All in all pretty interesting but I have not been able to do any measurements of memory savings in context of OSv (yet). 

Could also anybody confirm if any/all 3 graalvm-* examples work on their distributions? Please, note that the produced apps are regular Linux executables that should run on both Linux and OSv as is.

I tried apps/graalvm-netty-plot on my Fedora 29. I think it download a terabyte of stuff ;-) But it seems to work - I ran

scripts/run.py --forward tcp::8080-:8080 and set my browser to http::/localhost:8080, and saw some graph. And no error message or crash or anything bad. Nice.

Thanks. 

--
You received this message because you are subscribed to the Google Groups "OSv Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to osv...@googlegroups.com.