 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 121: Application Isolation API Specification
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: An API for initiating and controlling computations isolated from each other to varying degrees. Some API semantics are similar to those of ThreadGroup. Please direct comments on this JSR to the Spec Lead(s) Team
Note that this JSR was completed under JCP 2.1, and moved to JCP 2.6 after completion. Updates to the Original Java Specification Request (JSR) The following updates were made to the original JSR. Specification Lead: Krzysztof Palacz E-Mail Address: krzysztof.palacz Telephone Number: +1 650 786 6119 Fax Number: +1 650 786 2141 For additional information, sample draft APIs, and access to an interest-group mailing list for JSR-121, go to http://bitser.net/isolate-interest/. Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Sun Microsystems Name of Contact Person: Pete Soper E-Mail Address: pete.soper@sun.com Telephone Number: +1 919 460 2991 (USA East Coast) Fax Number: +1 919 481 1698 Specification Lead: Pete Soper E-Mail Address: pete.soper@sun.com Telephone Number: +1 919 460 2991 Fax Number: +1 919 481 1698 Initial Expert Group Membership: IBM Additional Members expected:
Section 2: Request
2.1 Please describe the proposed Specification: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 sharing (see section 3.1) 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. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)J2SE. However, no platform restrictions are intended, and there is strong interest in wholesale adoption by J2ME. 2.3 What need of the Java community will be addressed by the proposed specification?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 implementation artifacts. 2.4 Why isn't this need met by existing specifications?Java includes a class loader class with namespace related features that in combination with additional threads offer support for multitasking. However the actual isolation of applications sharing a virtual machine context is inadequate: some portions of Java state may be shared, and sometimes this sharing is not obvious. This leads to many interference scenarios that can prevent use of class loaders for multitasking, especially if an arbitrary mix of application code is allowed. Application failures within this context are frequently subtle and hard to reproduce, and misbehaving applications are difficult or impossible to remove. This prevents even basic resistance to denial of service attacks. The Runtime.exec() method allows for programmatic execution of new Java (or other) applications in separate processes but Java offers little means of monitoring or control and those that are available have to do with OS processes, not Java applications. In short there are no API means of effectively managing multiple applications in a secure and scalable manner. There are no Java interfaces related to sharing of platform resources. Although this kind of sharing is typically viewed as an implementation feature transparent to users there are requirements for exposure in some cases. But more fundamentally users must be able to determine what implementation qualities they are getting: existing formal and informal Java interfaces make this difficult or impossible. 2.5 Please give a short description of the underlying technology or technologies: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 SDK implementers. 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. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)java.lang or java.lang.isolate 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No. 2.8 Are there any security issues that cannot be addressed by the current security model?No. 2.9 Are there any internationalization or localization issues?No. 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?Some System and Runtime methods will require minor changes to their semantic definitions to provide the notion of a logical virtual machine when the API is used with certain VM features. When the API is not used there will be no change in the behavior of either class and no backward compatibility issues. When the API is used with single VM multitasking features it is expected that application management code may be concerned with these semantic changes: the managed applications themselves should see no differences. See the Isolate Appendix in 3.1. 2.11 Please describe the anticipated schedule for the development of this specification.The goal is to include this specification in the J2SE 1.5 (Tiger) umbrella JSR. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.Application Isolation in the Java(tm) Virtual Machine, Grzegorz Czajkowski, ACM OOPSLA'00, Minneapolis, MN, October 2000. Automated and Portable Native Code Isolation, Czajkowski, G., Daynes, L., and Wolczko, M., Sun Microsystems Laboratories Technical Report 01-96, April 2001. Experience with Secure Multi-Processing in Java, Dirk Balfanz, Li Gong, IEEE Proceedings of ICDSC'98, Amsterdam, The Netherlands, May 1998. Building a Java virtual machine for server applications: The Jvm on OS/390 Dillenberger et al IBM Systems Journal (Java Performance issue), Volume 39, No. 1, 2000. 3.2 Explanation of how these items might be used as a starting point for the work.The Isolate Straw Man Classes and Appendix describe most of the API and its implications for existing interfaces. Notably absent are additional class constructor (or factory method) signatures, in particular as they relate to a means of testing for and selecting implementation features. While the expert group will determine the details of the API, it appears desirable for API users to directly use or extend a class that in turn implements API methods contained in a Java interface. The simple class declaration of the Isolate straw man hides this expectation for the sake of simplicity. A state transition diagram and a diagram relating isolation and sharing to the API are also provided. The application isolation paper describes strategies for single-VM execution of multiple applications in a secure manner and prototype implementations employing byte code editing and VM runtime modifications. Sun has created additional experimental implementations of isolated application support in the runtimes of two full featured Java virtual machines. We expect to be able to share details of these experiments at a future time. This research does not imply product development on Sun's part. The native code isolation paper describes a means of extending the isolation model to a notoriously vexing area. The secure multi-processing paper describes early efforts to attempt to use class loaders to support multi-tasking. The Dillenberger paper describes a VM implementation offering a high degree of application isolation and resource sharing and very low execution latencies. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
