Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Should Isolates be given a second chance?
URL: The problem that Java Isolates solve
At 2:33 AM on Jan 17, 2008, cowwoc wrote:
Fresh Jobs for Developers Post a job opportunity
Recently, however, I read something that got my attention. Isolates enable the JVM to run multiple pseudo-processes with a near-efficiency of threads. Why is this a big deal? Because there are many use-cases that could benefit from process-isolation but their cost forces us to risk using threads instead. Isolates improve thread-safety for concurrent software and as more multi-core machines roll out this topic becomes even more relevant in our daily lives.
Here are some examples of how Isolates could help:
1) One web-app should not be able to negatively impact another by consuming its memory, cpu, or otherwise altering its state. One misbehaved webapp could conceivably take down the entire server and this happens in practice.
2) Mobile-code (used in applets, grid-computing, etc) would benefit greatly from exactly this kind of isolation to prevent it from taking down your browser, machine, etc. If a new security model enabled mobile-code to become more mainstream in Java applications it would open the doors to a lot of new opportunities that other platforms couldn't compete with. This is a possible killer feature that could benefit many everyday applications, such as P2P software.
Java's Security Manager does a great job on many fronts but two sectors it does not help with is memory and cpu usage. There is no good way to prevent a thread from consuming more memory or CPU time than you want it to and taking down the rest of the process with it.
I've only listed two examples above but I suspect many of you could come up with others that could benefit from extra isolation.
Finally, I think the best part of this JSR is that it does not require a language change . I'm hoping this means you'll have less to fight about
I'm not personally advocating the exact design outlined in JSR 121 but rather I'm saying that the use-cases it aims to solve are indeed worthy of our attention. At first glance, this JSR seems to have a minimal impact on the API, learning curve, and cost to implement a prototype.
17 replies so far (
Post your own)
Re: Should Isolates be given a second chance?
> Recently, however, I read something that got my> attention. Isolates enable the JVM to run multiple
> pseudo-processes with a near-efficiency of threads.
Naive implementation of Isolates can be done by spawning separate jvm for each of them. In such case Isolate API will be just glorified exec, tailored for jvm (so you don't have to mess with command line parameters too much).
I assume that you expect 'proper' implementation, which would cover considerable amount of sharing between the jvms. This is the idea of MVM, which doesn't have to really implement Isolates (it will be just very easy to do it) - MVM should be smart enough to be enabled even for separately running jvms, started from command line. In some way, you could imagine java.exe being just a frontend to one big MVM spawning Isolates for each invocation.
Now, as far as I know, biggest problem with MVM is proper handling on JNI code/native resources, so one rogue JNI library cannot kill MVM by messing with random pointers. This unfortunately means creating OS kernel-like solution, with page protections and non-trivial communication between child Isolates and parent MVM. Whatever ideas you will come with, there will not come for free - question is the performance cost (0.1%? 1% ? 50%?)
IMHO, it won't happen soon. Complexity of MVM done right is really, really big. There are still not fixed JVM crashes caused by innocent code, I'm afraid to think what would happen with full MVM.
Re: Should Isolates be given a second chance?
> I assume that you expect 'proper' implementation,> which would cover considerable amount of sharing
> between the jvms. This is the idea of MVM, which
> doesn't have to really implement Isolates (it will be
> just very easy to do it) - MVM should be smart enough
> to be enabled even for separately running jvms,
> started from command line. In some way, you could
> imagine java.exe being just a frontend to one big MVM
> spawning Isolates for each invocation.
I don't disagree with your points. However, I think it is worth nothing that Isolates and MVM don't necessary have the same goal and implementing one might be more complex than the other.
I think Isolates brings something to the table which MVM did not: simply cross-process communication. MVM is meant for running unrelated applications under the same JVM whereas Isolates are meant for running related (but isolated) applications under the same JVM that communicate using a controlled method. Whereas MVM is highly affected by the safety of JNI code (because you can't control what unrelated applications want to run) Isolates are not necessarily as affected by it because your use-case might very well not require JNI use at all. You could then enforce this restriction by disallowing the use of JNI code in your application using the existing security manager and Isolates would still add a lot of value to your application.
Java's security manager was a huge step for loading untrusted mobile-code (or plugins if you prefer to think of them that way). Isolates would add security value regardless of the MVM use-case and that's welcome news.
Maybe what we need to do is separate out these two concerns:
1) We need a way to dictate the memory/cpu usage policy in a way that the current SecurityManager does not allow.
2) We need a way to isolate threads from accessing each other's memory.
Re: Should Isolates be given a second chance?
A ProcessBuilder based JSR-121 implementation would be enough for my purposes--especially if it came with a resource monitoring API. Provide a good API now, and improve the implementation if needed. Isn't that the Java ideal?Re: Should Isolates be given a second chance?
> A ProcessBuilder based JSR-121 implementation would> be enough for my purposes--especially if it came with
> a resource monitoring API. Provide a good API now,
> and improve the implementation if needed. Isn't that
> the Java ideal?
That sounds exactly like what I'm looking for
Re: Should Isolates be given a second chance?
JSR-121 doesn't specify implementation. See the "Implementation Styles" slide.http://bitser.net/isolate-interest/slides.pdf
I took a few hours one day to try implementing JSR-121 using java.lang.ProcessBuilder. After getting to the point where everything compiled, it looked like getting all of the tests to pass would be about a week of work. I was planning on using RMI to pass objects between isolates. Further experience with RMI has led me to believe that simple serialization would be a better choice.
Re: Should Isolates be given a second chance?
> I took a few hours one day to try implementing> JSR-121 using java.lang.ProcessBuilder.
I fail to understand how implementing it with ProcessBuilder would give you "near-efficiency of threads" cowwoc wanted. In such implementation, Isolation API is just way to start the jvm in crossplatform way plus bits of inter-process communication.
Re: Should Isolates be given a second chance?
I'm interested in isolates for isolation. That seemed to be the primary interest of cowwoc as well. You're absolutely right about a ProcessBuilder based implementation being "just [a] way to start the jvm in crossplatform way plus bits of inter-process communication". That's more than enough benefit to make it worth doing. Lack of isolates is a big hole in the JRE.Heck, java isn't even in the tools package.
http://java.sun.com/javase/6/docs/api/javax/tools/package-summary.html
You seem to be implying that a ProcessBuilder based implementation wouldn't be worth doing for performance reasons. I'm sure there are lots of problems that would see great performance benefits from some specific isolate implementation. There are also lots of problems where the performance with all of the options being discussed is essentially identical.
In a very real way, even the (I think relatively rare) cases that don't perform well under a simple implementation, argue for adding an implementation to the JRE. It allows those applications to be written once, and improved without being modified when a better implementation becomes available.
At this point this is a pretty academic discussion. I doubt anyone will contribute a ProcessBuilder based JSR-121 implementation to the community.
Re: Should Isolates be given a second chance?
There's another potential benefit too. If each isolated application has essentially its own private heap, then they can be garbage collected independently. There would be no need for a 'stop the world' garbage collection for the whole JVM. If isolated apps are cheap and easy to spawn, then then a large application could be constructed out of lots of small ones and performance overall may actually improve.Re: Should Isolates be given a second chance?
> There's another potential benefit too. If each> isolated application has essentially its own private
> heap, then they can be garbage collected
> independently. There would be no need for a 'stop
> the world' garbage collection for the whole JVM. If
> isolated apps are cheap and easy to spawn, then then
> a large application could be constructed out of lots
> of small ones and performance overall may actually
> improve.
I'm replying to myself, so that can't be good. Anyway, one thing I forgot to mention, is that the whole isolate thing reminded me of Erlang's lightweight processes. Erlang already has per-lightweight-process, independently garbage collected heaps in the same operating system process.
Re: Should Isolates be given a second chance?
That reminds me of another implementation option. Isolates could be implemented using the JVM itself.The Squawk Virtual Machine
http://research.sun.com/projects/squawk/squawk-rjvm.html
Implementation of something like Erlang on the JVM is one of the reasons isolates interests me. I don't know if that would typically create too many processes for the one-isolate-per-process model.
Re: Should Isolates be given a second chance?
> That reminds me of another implementation option.> Isolates could be implemented using the JVM itself.
>
> The Squawk Virtual Machine
> http://research.sun.com/projects/squawk/squawk-rjvm.ht
> ml
>
> Implementation of something like Erlang on the JVM is
> one of the reasons isolates interests me. I don't
> know if that would typically create too many
> processes for the one-isolate-per-process model.
Squawk looks very interesting indeed, but I'm not sure how this related to isolates. What did you have in mind?
Re: Should Isolates be given a second chance?
> Squawk looks very interesting indeed, but I'm not> sure how this related to isolates. What did you have
> in mind?
From the webpage:
An isolate is a mechanism by which an application is represented as an object. In Squawk, one or more applications can run in the single JVM. Conceptually, each application is completely isolated from all other applications. Given the immutability of suites, the isolate implementation in Squawk shares common suites between applications. This can significantly reduce the memory footprint of each application, which is particularly important in the embedded device space.
Re: Should Isolates be given a second chance?
> > Squawk looks very interesting indeed, but I'm> not
> > sure how this related to isolates. What did you
> have
> > in mind?
>
> From the webpage:
>
> An isolate is a mechanism by which an application is
> represented as an object. In Squawk, one or more
> applications can run in the single JVM. Conceptually,
> each application is completely isolated from all
> other applications. Given the immutability of suites,
> the isolate implementation in Squawk shares common
> suites between applications. This can significantly
> reduce the memory footprint of each application,
> which is particularly important in the embedded
> device space.
The more I read about Squawk the more I'm impressed. Any idea why this implementation never saw the light of day? Is it still being actively developed?
Suites sound a lot like super-packages that Sun plans on adding into Java7 and the Squawk page claims "On average, suites are one third of the size of class files. [...] This results in a significantly reduced start up time when running an application from a suite (as opposed to a dynamically loaded set of classes)." which is very nice.
Re: Should Isolates be given a second chance?
Wow, just wowThe FAQ seems to indicate that Sun is planning to open-source this in the near future. Now if only they had Squawk for the full-fledged JavaSE...