Jres: a Resource Accounting Interface for Java
Total Page：16
File Type：pdf, Size：1020Kb
In Proceedings of the 1998 ACM OOPSLA Conference, Vancouver, BC, October 1998. JRes: A Resource Accounting Interface for Java Grzegorz Czajkowski and Thorsten von Eicken Department of Computer Science Cornell University Ithaca, NY 14853 USA +1 607 255 5951 {grzes,tve}@cs.cornell.edu ABSTRACT retrieval to accessing proprietary databases to With the spread of the Internet the computing model on dynamically uploading services. These tasks can be server systems is undergoing several important changes. accomplished via a concept of servlets [23] — untrusted Recent research ideas concerning dynamic operating code executed on the server. The programming language system extensibility are finding their way into the Java is currently a premier tool for implementing such commercial domain, resulting in designs of extensible uploadable content. databases and Web servers. In addition, both ordinary Despite the attention and publicity given to Java, most users and service providers must deal with untrusted notably to its security features, there are still areas where downloadable executable code of unknown origin and Java either cannot be applied or applying the language is intentions. cumbersome and requires non-portable native code Across the board, Java has emerged as the language of support. The language has been extended in various ways choice for Internet-oriented software. We argue that, in and its performance has been continuously improving. order to realize its full potential in applications dealing However, the current definition of Java (version 1.2) with untrusted code, Java needs a flexible resource does not have an interface for resource management. The accounting interface. The design and prototype application domains that would benefit from providing implementation of such an interface — JRes — is such an interface as a standard and integral part of the presented in this paper. The interface allows to account language specification include both well known for heap memory, CPU time, and network resources paradigms, such as application-controlled load balancing consumed by individual threads or groups of threads. and preventing some denial-of-service attacks, as well as JRes allows limits to be set on resources available to emerging concepts, such as extensible servers. threads and it can invoke callbacks when these limits are Not addressing the issue of resource management may in exceeded. The JRes prototype described in this paper is fact be an adequate decision when designing a “plain” implemented on top of standard Java virtual machines and programming language. This is not so in the case of Java, requires only a small amount of native code. which is both a language and a runtime environment and Keywords includes many features of an extensible operating system Java, resource management, extensible systems. (a Java-enabled browser is in essence an operating system running applets). Server-side environments running INTRODUCTION untrusted code are being developed and may well become The spreading use of active content on the Internet makes common [20,23]. The fact that Java provides neither a the use of untrusted code a fact of life for connected users model nor mechanisms for controlling resource as well as for providers of Internet-based services. On the consumption of applications (apart from changing thread client side, downloadable executable content, like Java priorities) is a problem in all these systems for two applets [2] and Active X technology [11], serves to reasons: malicious code cannot be prevented from using increase the attractiveness of Web pages. On the server too many resources and code cannot be charged for the side, dynamic server extensibility promises full resources it is consuming. Both issues represent a customizability of various tasks, from information significant obstacle to deploying commercial extensible servers. Some ad-hoc resource controlling solutions are possible in Java. For example, using native code it is possible to monitor CPU time consumed by each thread. Such approaches tie an otherwise portable Java environment to an underlying operating system, which results in loss of portability and maintenance problems. Enforcing appropriate resource consumption patterns is also possible sections discuss related work, the current status of the for applications where one has full control over the system and planned future directions. The last section sources and can “make the code behave”. However, in the summarizes the paper. case of untrusted and unknown code, like applets and MOTIVATING APPLICATIONS servlets, no assumptions can be made about resource Several motivating examples are described below in order consumption. to clarify why it is crucial that Java (and any other In this paper we propose JRes — a Java interface which language of similar scope) provide a resource allows per-thread accounting of heap memory, CPU time, management interface. Such an interface should at least and the number of bytes sent and received. In addition to allow the resources consumed by applications (be it tracking resource consumption, applications can be applets or servlets) to be monitored and limits on the informed when new threads are created. JRes provides consumption of particular resources to be enforced. mechanisms for setting limits on the resources available The first group of applications that can readily benefit to particular threads and associate overuse callbacks to be from JRes are extensible, Java-based Internet servers, invoked whenever any such resource limit is exceeded. which allow service extensions to be uploaded by clients Although the interface is simple, it is flexible enough to to the server. Consider image processing services created support a variety of resource consumption enforcement for profit by an independent developer. An architecture of policies. For instance, a policy which ensures that no an extensible Web server makes it possible for the thread gets more than 100 milliseconds of CPU time out developer to upload the code of the service. This makes of every second is easily expressible, as will be shown the service available to a large group of potential users. later. Similarly, a few lines of code suffice to create a Clients access the services either via a standard Web policy in which no thread group can send more than 2MB browser interface or, in case of more sophisticated or of data, or a policy in which the combined size of all alive special demands, are able to upload their own code objects allocated by threads belonging to a particular accessing the image-rendering services. thread group does not exceed 1MB. The J-Server, a practical application of the J-Kernel, is an Although the design of JRes is general and the system can example of a dynamically extensible Web server [20], be used for any Java application, its main intended usage adequate for implementing such scenarios. Both the is for extensible environments, like Web browsers or system core and the uploaded code execute in a single extensible Internet servers. Such environments would use Java Virtual Machine (JVM). Constructing a server as a JRes to control resources consumed by their extensions. single JVM has two considerable advantages. First, the The contribution of this paper is twofold. First, it performance of cross-domain calls between the core and motivates considering incorporating a resource extensions is much better than when relying on traditional management interface in the language specification of OS protection mechanisms (e.g. separate processes Java and any other language of similar aspirations and encapsulating extensions and the core). Second, the scope. By describing several possible applications of JRes security restrictions under which bytecode is run can be we aim at making a convincing argument that future finely controlled and Java provides adequate mechanisms extensions of Java with resource management support for extensibility and implementing protection domains should provide at least the functionality included in JRes. [20,15]. The second goal is to demonstrate that although it was While the issues of dynamic extensibility and protection possible to implement JRes in its current form without are well understood in the context of Java, the lack of modifying the underlying JVM, it comes at a price of support for resource accounting has two serious certain functionality limitations and performance consequences. First, in a single-address space overheads. The lessons learned in the course of environment described above, it is difficult to identify developing JRes can be important guidelines in future servlets that consume too many resources. Malicious work on resource management infrastructure for Java, servlets can easily mount denial-of-service attacks, that is, possibly through changing the implementation of JVMs. attacks aimed at preventing other applications from being Although the JRes project is carried out in the context of able to use resources. Second, one of the main incentives Java, it is applicable to other languages with features behind attractive, high quality, extensible Internet servers similar to Java. To date we are not aware of any other is the revenue they may potentially bring. Lack of support work providing the functionality of JRes in a general for resource accounting leaves only one alternative for purpose programming language. billing users: flat, undifferentiated fees. Although in The rest of the paper is structured as follows. The next principle flat