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 <[email protected] > <javascript:>> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/osv-dev/09b6717f-632c-4faf-8fc1-a3b72f40e7f2%40googlegroups.com >> >> <https://groups.google.com/d/msgid/osv-dev/09b6717f-632c-4faf-8fc1-a3b72f40e7f2%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/9b3f47f3-b821-4ac8-931d-f77ad11bfc20%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
