Google has posted the proposed final draft review of JSR-284 Resource Consumption Management API to the Java Community Process. According to the JSR,
Software systems in many circumstances need awareness of their resource usage. Meeting performance requirements often requires the ability to manage consumption of resources provided by the environment. Resource management is traditionally handled by operating systems, but the growing need to use the Java platform in the systems programming domain adds increased pressure to equip it with resource management capabilities at a level of abstraction that fits gracefully with the language.
Preventing denial of service attacks, providing load balancing, and monitoring the usage of a given resource are all difficult to do in the current version of the Java platform. In general, these and other features cannot be provided without going beyond the Java language proper, through mechanisms such as native code or shell scripts that ask the OS to handle matters related to resource management. The lack of a standard, programmatic way to partition resources available to virtual machine(s) among Java applications has led to a number of ad-hoc solutions.
The Resource Management API for J2SE Applications should address the above and be characterized by the following:
- Wide applicability. The interface should be applicable to a variety of resource management scenarios and allow the expression of numerous resource management policies.
- Flexibility. The interface should enable managing a broad range of resource types. For example, for some applications resources such as the CPU time and heap memory matter most, while other applications may find it more meaningful to manage higher-level resources, such as the number of open JDBC connections or the number of transactions per second, and the API should accommodate this entire spectrum.
- Extensibility. The resource management interface should support the addition of new resources in a uniform manner.
- Completeness of abstraction. The interface should hide from applications whether a given resource is managed by the underlying operating system (OS), by the Java Virtual Machine (JVM), by a core library, or by trusted middleware code. As a consequence, it should be possible to write resource policies for resources exhibiting common behavior abstractly, without regard for how those resources are implemented.
- Lack of specialization. The interface should not require an implementation to depend on specialized support from an OS or from hardware, although implementations should be free to take advantage of such support if available.
- Ease of exposing resources through the API in a low-overhead fashion.
- Diagnosability. It should be straightforward to determine cause(s) of an application running into resource constraints.
- Simplicity of use. While excercising the full power of the API may require expert knowledge, it should be simple to perform common resource management tasks.
Concrete examples are given below to demonstrate the need for and usefulness of the proposed specification. None of them can be realized by current APIs.
- An application management environment needs to confine each application to at most 32MB of heap memory and would like to detect applications that use more than 90% of CPU time in order to terminate them. Moreover, a minimal quantity of heap and CPU should be reserved for each application to ensure a basic level of service.
- An application would like to be notified when its usage of network resources exceedes 10MB/s, so that it can start compressing data before sending it, but only if the total CPU time consumption is below 50% (effectively this policy is about trading one resource for another).
- A service provider would like to understand (for profiling or billing purposes) how much of each resource of interest (memory, CPU time, SQL statements submitted over JDBC connections, etc.) each user is consuming.
- A service provider would like to distinguish between users with "platinum", "gold", and "silver" contracts and offer them different QoS level. This translates into the need to partition resources according to the contractually agreed upon QoS.
The API should enable resource management policies to be programmed. In particular, such a policy should have the ability to define when an application may gain access to, or consume, a unit of a specific resource. It should be possible to bind computations dynamically to policies. Programs should be able to reserve resources in advance and thus ensure predictable execution. Applications should be able to install resource monitoring code so that proactive programs can observe resource availability and take any actions required to ensure performance and availability or to ward off denial of service attacks. Existing applications should run without modification, even if the Java platform classes or the Java runtime environment they depend depend on exploits the resource management framework. The interface should not impact in any way how actual resource providers (schedulers, automatic memory subsystems, etc.) should be written - it should be possible to make these providers become "RM-enabled" by inserting calls to appropriate API methods to convey information about resource consumption attempts. The effort required to retrofit existing resource managers should thus be minimized.
The specification will build upon the abstraction of an isolate, as defined in JSR 121. An isolate is an encapsulated Java program or application component that shares no state with other isolates. Isolates are a convenient abstraction on which to develop resource management: isolation allows unambiguous resource usage accounting and clean reclamation upon program termination. The expert group will also look at enabling the API to operate on platforms that do not support the Isolate API. In particular, a single JVM could be viewed as a special case of a single isolate.
In addition to defining an API, which will be a framework through which resources can be uniformly exposed to client programs as entities subject to management, the outcome of this JSR will include a non-empty set of resources deemed core and required by compatible implementations.