A. L. Hosking, J. E. B. Moss, and C. Bliss. Design of an object faulting persistent Smalltalk. Technical report, Univerity of Massachusetts, 1990. UM-CS-1990-045.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....pool when required. The Mneme design also provides support for transactions and recovery that is beyond the scope of this review; see [41] for further details. Persistent Smalltalk A number of different implementations of persistent Smalltalk are described in the various Mneme papers primarily [32] and [31] All provide transparent orthogonal persistence to applications and rely on object faulting. They differ in the swizzling strategies and or object fault detection mechanisms used. The implementations were (mostly) carried out by modifying the Smalltalk virtual machine (encompassing the ....

....objects and edges represent object references, edge marking marks all references to non resident objects while node marking marks all nodes of the object graph that represent non resident objects. Early implementations of persistent Smalltalk using both edge and node marking are described in [32]. Since Smalltalk already used tagged pointers, the edge marking implementation used an unassigned tag value to mark references to non resident objects and stored the 28 bit Mneme client identifier for the target object in the remainder of the reference. The virtual machine performs a check on ....

Antony L. Hosking, J. Eliot B. Moss, and Cynthia Bliss. Design of an object faulting persistent smalltalk. Technical Report COINS Technical Report 90-45, Department of Computer and Information Science, University of Massachusetts at Amherst, May 1990.

....the invocation of statically determined procedures. Ignoring possibilities for optimization of residency checks based on local global data flow analysis, every dereference requires a residency check. 1 [ACC82, BC86, KK83, Kae86, CM84, RMS88, SMR89, BBB 88, Ric89, RC90, Ric90, SCD90, WD92, HMB90, Hos91, HM93a, LLOW91, SKW92, WK92] Static OO: Object oriented programs execute through the invocation of methods on objects. A method typically accesses the encapsulated state of its target object. Thus, applying the pinning and target residency rules eliminates all residency checks on the ....

Antony L. Hosking, J. Eliot B. Moss, and Cynthia Bliss. Design of an object faulting persistent Smalltalk. Technical Report 90-45, Department of Computer Science, University of Massachusetts at Amherst, May 1990.

....fault causes a non resident page to be brought into physical memory, an object fault causes the retrieval of a non resident object. We call that part of the persistent heap that is in main memory volatile since only objects in memory can be manipulated and updated. Our version of object faulting [7, 8, 9] is being used to implement persistence for Smalltalk and Modula 3 [5] Here, we concern ourselves with management of the volatile heap, and the requirements imposed by persistence on the techniques used. We present a design that allows reclamation of storage in the volatile heap, with garbage ....

A. L. Hosking, J. E. B. Moss, and C. Bliss. Design of an object faulting persistent Smalltalk. COINS Technical Report 90-45, University of Massachusetts, Amherst, MA 01003, May 1990.

....We can consider all such referenced data items (both persistent and volatile) as a kind of virtual heap. Object faulting does not preload the entire heap; rather, objects are faulted on demand. Our design of Persistent Smalltalk makes object faulting the responsibility of the run time system [Hosking et al. 1990]. All references to non resident objects are trapped by the Smalltalk virtual machine. Certain heuristics are used to restrict residency checks to just the send bytecodes and some primitives. This approach is purely dynamic in that no changes are made to the Smalltalk compiler or image. Our ....

....two built in object types, one traced and the other untraced, having no fields or methods, from which all object types are descended: ROOT and UNTRACEDROOT. 2 We can summarise the subtype rules for references as follows: 1 We may also apply certain heuristics to this problem. For details see [Hosking et al. 1990]. 2 Shorthands OBJECT. END and UNTRACED OBJECT. END may be used for the forms ROOT OBJECT. END and UNTRACED ROOT OBJECT. END, object types inheriting from ROOT and UNTRACEDROOT, respectively. NULL : REF T : REFANY NULL : UNTRACED REF T : ADDRESS NULL : T OBJECT. END : T, for some ....

Antony L. Hosking, J. Eliot B. Moss, and Cynthia Bliss. Design of an object faulting persistent Smalltalk. COINS Technical Report 90-45, Department of Computer and Information Science, University of Massachusetts, Amherst, MA, May 1990.

.... or combining residency checks, or imposing special rules that complicate the compiler such as: the first argument of 1 For further information on Modula 3 see [CDG 88, CDG 89, CDG 91, Nel91, Har92] for further information on our persistence work see [MS88, Mos89, Mos87, Mos90, HMB90, HM90, HM91, Hos91, Mos92, HM93a, HBM93, HM93b] a method call (i.e. the target object) will (somehow) automatically be made resident throughout the execution of the method (so that the method code need not contain checks on uses of the target object) Implementing these optimizations would ....

....must also integrate support for concurrency control, recovery, and distribution, but we focus primarily on object residency aspects of persistent systems here. A wide range of object faulting schemes have been devised ( ACC82, BC86, KK83, Kae86, CM84, RMS88, SMR89, BBB 88, Ric89, SCD90, WD92, HMB90, Hos91, HM93a, LLOW91, SKW92, WK92] are not exhaustive) Any scheme has some number of distinct situations, such as a reference to a resident object (which presumably can be used without causing an object fault) versus a reference to a non resident object. We are concerned only with situations ....

Antony L. Hosking, J. Eliot B. Moss, and Cynthia Bliss. Design of an object faulting persistent Smalltalk. COINS Technical Report 90-45, University of Massachusetts, Amherst, MA 01003, May 1990.

.... as to represent 1 Atkinson et al. 1982; Brown and Cockshott 1986; Kaehler and Krasner 1983; Kaehler 1986; Copeland and Maier 1984; Riegel et al. 1988; Straw et al. 1989; Bancilhon et al. 1988; Richardson 1989; Richardson and Carey 1990; Richardson 1990; Schuh et al. 1990; White and DeWitt 1992; Hosking et al. 1990; Hosking 1991; Hosking and Moss 1993a; Lamb et al. 1991; Singhal et al. 1992; Wilson and Kakkad 1992 only marginal overhead to frequently executed operations on fine grained objects. Nevertheless, even marginal overhead will have a cumulatively significant impact on overall performance. Thus, ....

....only marginal overhead to frequently executed operations on fine grained objects. Nevertheless, even marginal overhead will have a cumulatively significant impact on overall performance. Thus, any opportunity should be exploited to elide residency checks where they are not strictly necessary [Hosking and Moss 1990; Hosking and Moss 1991; Moss and Hosking 1994] Such optimizations rely on data flow analysis and code transformations (e.g. hoisting or combining residency checks) and the imposition of special rules about the residency of particular objects. Example rules and their ramifications include: ....

HOSKING, A. L., MOSS, J. E. B., AND BLISS, C. 1990. Design of an object faulting persistent Smalltalk. Technical Report 90-45 (May), Department of Computer Science, University of Massachusetts at Amherst.

No context found.

A. L. Hosking, J. E. B. Moss, and C. Bliss. Design of an object faulting persistent Smalltalk. Technical report, Univerity of Massachusetts, 1990. UM-CS-1990-045.

No context found.

A. L. Hosking, J. E. B. Moss, and C. Bliss. Design of an object faulting persistent Smalltalk. Technical report, Univerity of Massachusetts, 1990. UM-CS-1990-045.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC