Hi all
After reading the post "Java EE applications as first class citizens" (
http://weblogs.java.net/blog/jjviana/archive/2010/08/16/my-top-wish-java-8-ee-applications-first-class-citizens), I've been wondering about a probably crazy idea about how it might be done.
Java EE containers are currently a lot like pre-protected-memory operating systems. Apps can delve into the guts of the container fairly freely, especially if permitted to use reflection, which is increasingly necessary for Java apps. It's hard for the container to strongly separate its resources from those of the applications , and applications from each other. This is particularly the case where pooled resources (threads, jdbc connections, etc) are involved. It's hard for the container to completely kill and unload an application, or protect one app from another.
I find myself extending that OS/kernel parallel and thinking about the possibility of the container's JVM using hardware VT-X instructions to isolate the container "core" from applications, each of which would get its own virtual memory mapping. The container could set up the page tables so it can see all of the apps' memory, but each app can only see its own memory and that part of the container's memory that it exposes for public interfaces to use. Follow a reference (even if obtained by reflection etc) to inaccessible memory in the container's private mappings or another app's private mapping and you get a hardware segfault that can be trapped and turned into a suitable exception.
The fact that VT-X isn't usable inside virtualized guests might be a big road-block - sadly, it doesn't nest. OTOH, if you were offering Java hosting, the whole idea would be to isolate apps well enough that you wouldn't *need* OS level virtualization as well...
Is it completely crazy to think about using hardware memory protection features to isolate a container from its apps? And let the same protection permit easy and comprehensive cleanup of killed applications by dropping their memory mappings?
The alternative approaches to providing isolation between a container and its apps would have to be either multi-JVM IPC-driven, or a pure-software isolation implementation within the JVM its self. An IPC-driven multi-process approach would need multiple JVMs - one for the container and one per app - with a shared-memory segment or similar IPC system, so the OS could be used to kill off an app and clean it up. The alternative, implementing all that isolation purely in software, seems doomed to be a complexity nightmare - as people who've tried to provide inter-application protection in regular OSes without using hardware memory protection have found in the past.
Thoughts? Flames?
[Message sent by forum member 'ringerc']
http://forums.java.net/jive/thread.jspa?messageID=481243