On Tue, Apr 19, 2011 at 2:55 AM, Miles Sabin <[email protected]> wrote: > On Tue, Apr 19, 2011 at 4:51 AM, David Schlosnagle <[email protected]> wrote: >> I'd be interested to see what you find. Here are a few links [1] [2] [3] >> from a few years back when I did a little investigation of isolating >> multiple apps in a single JVM. For my needs I ended up with separate JVMs to >> satisfy some other constraints (e.g. some components were focused on low >> latency responses, while others were focused on pure throughput, so it made >> sense to separate these and apply different GC policies). >> [1] Secure and Reliable Java-Based Middleware - Challenges and >> Solutions http://www.inf.usi.ch/faculty/binder/documents/ares06.pdf >> [2] JSR 121: Application Isolation API >> Specification http://jcp.org/en/jsr/detail?id=121 >> [3] JSR 284: Resource Consumption Management >> API http://jcp.org/en/jsr/detail?id=284
I was familiar with 121 but not 284. I remember taking in a talk on 121 at the first JavaOne I attended in 2004(!) > I'm sorry to say that both JSRs are long since dead. At the time the > main issues which seemed to be exercising Sun were memory footprint > and startup time. A multi-process JVM didn't do anything to address > those, quite the opposite in fact. And the Multitasking Virtual > Machine (a Sun Labs project led by Grzegorz Czajkowski, now at Google) > never had enough resources put behind it to make it into production. > In fact that was the main theme of the process ... Sun were > insufficiently committed to the project to put the resources into it > to make it a success as part of a mainstream JVM, and nor were any of > the other participants. It's unfortunate both of these died, but I assumed work on MVM had stopped some time ago. There was only hints of ongoing research when I joined Sun in 2006, but I never heard anything about it after an initial meeting with the Sun Labs guys. The virtualized JVM options seem like they're the most promising work at the moment. I know of both Azul and JRockit's virtualized JVM options, and I believe they have varying levels of support for OS-level virtualization like kvm (versus simply running atop e.g. Linux, which I believe Azul Zing can also do). It's interesting how few precedents I can come up with in mainstream software. Erlang may be the closest to solving this problem, since each executing "process" is isolated (even down to separate heaps?) and can be independently controlled, killed, spawned...exactly what we want here. Dalvik's forkable JVM may help reduce the duplicate VM/app cost across instances, but I've never played with the forking capability directly. This must also be a concern for all the Java clouds coming on line. GAE, Elastic Beanstalk have both dodged the issue. The former gives every concurrent request its own jetty server instance, and that server is spawned on demand (or ahead-of-time warmed-up) and killed when idle. The latter runs a normal Tomcat instance in its own EC2 instance. Both keep users completely isolated, by at least process boundaries and potentially by "machine" boundaries. Does anyone know if Google has OSSed the plumbing that routes and manages those jetty instances (he asks, knowing the answer is probably 'no'). If applications are sufficiently small, maybe all we really want is a set of simple tools that can spin up servers, point web requests at them, and kill them if they misbehave. That ought to be possible/easy with current JVMs, given enough memory to handle N JVM instances. - Charlie -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
