JavaFAQ Home » Good To Know
There is a strong desire for multitasking to get more work out of the Java
virtual machine. The negative effects of large initial footprint, large
increments of memory required by additional applications, and long startup
latencies, all hurt Java's ability to compete with more nimble and efficient
language systems and bring into doubt the prospects for scalability.
The need for freedom from inter application interference remains high as users
of Java mix ever more varied applications in their cell phones, on their
desktops and within their servers.
Ad hoc script and native code mechanisms for controlling and load balancing
multiple Java virtual machines in server settings hurt portability,
maintainability and robustness. There is a need for simple yet effective control
mechanisms that are tightly focused on Java applications instead of their
Java Isolates in an API. This API provides a uniform mechanism for
managing Java application life cycles that are isolated from each other, at
least with respect to object reachability, but that can potentially share
underlying implementation resources. It provides a means of deploying new Java
implementation features that enable and enhance scalability while providing an
alternative to ad hoc control schemes.
The API is intended to dictate implementation as little as possible. Different
implementations may provide different levels of isolation. All conformant
implementations must guarantee at least isolation of Java state (i.e. logically
disjoint heap spaces, per application mutable static fields, etc). Additional
forms of isolation possible include separation of JNI state and separation of
process state. Current Java implementations that provide execution of
applications in separate virtual machine instances can be wrapped with the
Isolation API by adding only a few mechanisms for control. Other implementations
might arrange for Java isolation in combination with high degrees of class,
bytecode, and native code sharing within the same VM or between multiple VMs.
Research by Sun and IBM has demonstrated these additional forms of isolation and
Selection of implementation specific features within the context of this API
will be via a combination of vendor specific and standard command line arguments
and properties. There will be a way to detect and select specific features so
API users know what they're getting. Additional interfaces may be required to
control implementation features related to isolation and sharing, but these are
outside the scope of this API.
The API consists of the Isolate class, which can be thought of as a handle to an
isolated computation, and a few new exception classes. Isolate object
instantiation corresponds to preparation of an isolated computation (an
application). Methods for starting, suspending, resuming, and terminating the
isolated computation are present, as well as methods for determining state,
waiting for termination, and determining familial relationships of computations.
Isolate operations that alter state make security checks that can throw security
exceptions. Isolate objects for access to existing computations can be obtained
through a static lookup method using identifiers that are unique within the
platform's domain (e.g. a computer, a cluster, etc).
Because computations managed by the API are isolated and, therefore, cannot be
expected to be able to detect the presence of each other except through use of
the Isolation API, we expect there to be a need for inter application
communication. No new communication mechanism is included with this API, and the
API does nothing to inhibit use of standard Java mechanisms like RMI. In
particular, the only dictated distinction between parent and child isolated
computations is the unique identifier of each: no object sharing between family
members is implied or provided by the API.
Resource control of isolated computations is outside the scope of this API. We
recognize that future efforts to add resource control APIs to the Java platform
will have to take this API into account.
A short description of the underlying technology.
The technology used to implement this API will vary widely depending on the
qualities of isolation (and sharing) SDK implementers are able to deliver with
it. A minimal conformant implementation delivering no additional qualities will
define the API's constructors or factory methods and regular methods but in most
cases may respond with an exception to signal the lack of new capabilities. A
key point here is that this API is not intended to put any onerous burdens on
A more effective implementation will extend the current process creation,
monitoring and control mechanisms available to many VMs. Means of starting,
suspending, resuming and terminating applications in other VM processes will be
implemented with IPC mechanisms such as signals and/or RPC. A key aspect of this
simple implementation is the capability of the Java VM to pause execution of the
Java application. This capability is already present in most VMs for properly
handling garbage collection.
Other implementations will add the ability of the API to create and manage
applications sharing a VM but isolated from each other at least at the Java
state level by arranging for separate logical or physical heaps, automatic
replication of mutable static class information and static system resources, and
handling of execution control with the proper granularity. Proper control of
native code generation and sharing by in-runtime compilers would complete the
collection of single-VM implementation features.
Other implementations of the API will add selectable features for explicit or
transparent resource sharing of immutable class data, byte codes and native
(compiled) code between VM processes.
Very good artincle on "Java Isolates" (By: Murali Kaundinya) can be
Look at this short excerpt:
"What Is Wrong with Classloaders?
Classloaders make it possible to load multiple instances of the same class. It's
possible to modify the search mechanism for class files within the JVM.
Classloaders act like a namespace whereby the classes loaded by a particular
classloader are tagged to provide a unique identity. With classloaders, it's
also possible to dynamically modify the bytecodes just prior to their loading by
performing certain transformations. An application can be unloaded by discarding
its classloader. However, a classloader can only be discarded if the reference
count for all the classes loaded by this classloader becomes zero and the
garbage collector deems them as unreachable. Classloader share basic classes;
this can be exploited to change the shared data, thus making the other
classloader and its applications vulnerable. The security model is debatable at
best. Here's an example: if there exists a utility class that's used by an
application and that application is distributed across two separate
classloaders, replicating the utility class in both of these classloaders is
obviously expensive. It's certainly possible to create a hierarchy of
classloaders and having the parent classloader load the utility class, thus
allowing the two classloaders to share code. Isolation provided by classloaders
is weak because objects can leak and be captured. This approach therefore is
incomplete and error-prone."
This article is based on JSR 121: Application Isolation API Specification, http://www.jcp.org/en/jsr/detail?id=121
"Java preps dive into real-time role" article at http://symbian.sys-con.com/read/99716.htm
Printer Friendly Page
Send to a Friend
Search here again if you need more info!