Lightweight Hardware Support for Protection in Object-Oriented Systems Jorg Kaiser, Karol Czaja German National Research Center for Computer Science Postfach 1316, SchloB Birlinghoven e-mail: [email protected] Abstract: The paper describes ACOM (Access Control Monitor), a hardware device which we developed to enforce run time protection in an persistent object-oriented system. To obtain a wide acceptance, the efSiciency of these systems must be comparable to conventional language systems. One of the key issues is to exploit the efJiciency of virtual memory management of contemporary processors. We will argue that a careful analysis of the hardware-software trade-ofl will lead to a simple hardware device which can efliciently support encapsulation and protection of small objects in an object-oriented systems. The main idea is to separate encapsulation and protection from address translation issues. 1. Introduction The object-oriented programming paradigm maps real world problems into a universe of objects in a machine. Ideally, everything a user of an object-oriented system is concerned with are objects. The system should provide a uniform interface to objects and remove the classical distinction between program-variables, files, or database items. A number of research and commercial projects in the area of object-oriented operating systems tried to provide objects as a general abstraction at the user interface [ 11 ,PI, [31 ,PI ,[SI ,[GI [81 without assuming any specially designed hardware platform. Of particular interest are those approaches which do not distinguish between the object model of the language and the system [5],[6],[7],[8],[9]. This has the following consequences on the support system: - the entire application is structured in arbitrarily sized objects. This means that the size of the objects is determined by the application and not by artifacts of the system architecture. Particularly, the system must cope with a large number of small objects as well as with very large objects. - individual objects should be the entities of protection and sharing. This implies that the architecture must recognize and protect those objects. - the system should directly support generic functions only, i.e. the least common denominator of all languages in question. This means that the system basically provides the containers for language objects, maps and protects them. In the following, we will concentrate on this basic functionality of an object support system. We will argue that a careful analysis of the hardware-software trade-off will lead to a simple hardware device which can efficiently support encapsulation and protection of small objects in an object-oriented operating systems. The main idea is to separate encapsulation and protection from address translation issues. The paper is organized as follows: In the next section we briefly sketch two examples of systems supporting persistent objects to show how these systems implement the persistent store on a pure software basis. We will argue that basic protection issues cannot efficiently be solved in these systems. The rest of the paper describes ACOM (Access hntrol Monitor), a hardware device which we developed to enforce run time protection. It easily could 264 0-81863015-9/92 $03.00 0 1992 IEEE Authorized licensed use limited to: IEEE Xplore. Downloaded on January 9, 2009 at 12:23 from IEEE Xplore. Restrictions apply.complement object-oriented persistent systems shown in the examples. Since only the most basic functions of encapsulation and protection are incorporated into the design, leaving the more complex and language dependent issues to software, it can be seen as a RISC approach to object-oriented hardware support. 2. Representation of persistent objects To exhibit the benefits of architectural support, we examine two example systems which provide basic support for persistent objects. We will concentrate on the Comandos system [7] and on an approach developed by Wilson [lo], although many other language and database systems use similar techniques [11],[12],[13]. We chose Comandos because it is a complete implementation of an object store addressing language and system aspects. Wilson's approach is sketched because he elegantly exploits available address mapping mechanisms to implement a persistent store. Both systems do not rely on special purpose hardware. The conceptual view of the persistent store in both systems is outlined in Fig.1. Both systems provide a shared persistent object store which includes all devices of a storage hierarchy. The system shields the programmer from the different addressing mechanisms found in the distinct storage media and allows a uniform location independent access to objects. The persistent object memory is constructed from a persistent passive space and a transient active space. The passive space is the long term object repository. Each persistent object has a representation in passive space. The active space constitutes a virtual address space where objects are directly accessible by a machine dependent address and where computations on objects are performed. However, for a programmer and even for a running program, the distinction is transparent and hence, conceptually, a single level store is provided. If a persistent object is referenced and it is not in the active space, it is automatically transferred from the passive to the active space by an appropriate manager. Once in active space, it should be possible to operate on objects as conveniently and with the same performance as in the runtime environment of a language. This particularly means, that it is mandatory to fully exploit all the hardware facilities of the basic processor, especially, virtual memory management and address calculation. The overhead one has to pay for persistence should only occur on the activation and passivation of objects. With a sufficiently large (machine supported) virtual memory and a certain locality of computation, acceptable performance can be expected [lo]. Therefore, we assume that the active space relies on a paged virtual memory because this is the standard supported by common address translation hardware and operating systems. petsirtent object memory 1I-l 1 persatmt pssiw spa pp - persistent panter II II va - virtual address active