Bidirectional Object Layout for Separate Compilation

Transcription

1 Proceedings of the 1995 AM onference on Object-Oriented Programming Sstems, Languages, and Applications (OOPSLA) Bidirectional Object Laout for Separate ompilation Andrew. Mers MI Laborator for omputer Science 545 echnolog Square ambridge, MA 02139, USA Abstract Existing schemes for object laout and dispatch in the presence of multiple inheritance and separate compilation waste space and are slower than sstems with single inheritance. his paper describes the bidirectional object laout, a new scheme for object laout that produces smaller objects and faster method invocations than existing schemes b automaticall optimizing particular uses of multiple inheritance. he bidirectional object laout is used for the programming language heta, and is applicable to languages like ++. his paper also demonstrates how to efficientl implement method dispatch when method signatures are allowed to change in subclasses. Most current staticall compiled languages require identical signatures for efficienc. 1 Introduction Existing schemes for object memor laout and method dispatch in staticall tped languages with multiple inheritance assume the use of multiple inheritance in its full generalit. hese schemes incur high per-object space overhead [Str87], extra dispatch cost, or a global tpe analsis phase [DMSV89]. Web site: andru/. his research was supported in part b the Advanced Research Projects Agenc of the Department of Defense, monitored b the Office of Naval Research under contract N J-4136 and in part b the National Science Foundation under grant R opright c 1995 b the Association for omputing Machiner, Inc. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that new copies bear this notice and the full citation on the first page. oprights for components of this work owned b others than AM must be honored. Abstracting with credit is permitted. o cop otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept, AM Inc., fax +1 (212) , or permissions@acm.org. hese problems are addressed b the bidirectional object laout, a new scheme suitable for separatelcompiled languages with multiple inheritance. he primar advantage of this object laout is that it supports faster method dispatch than current ++ implementations [ES90], while reducing the amount of per-object dispatch information. his paper presents precise rules for constructing bidirectional laouts and explains the dispatch code needed for tpical RIS architectures. Bidirectional object laouts can be efficientl computed because the construction rules use onl local knowledge of the tpe hierarch to compact the dispatch information. B requiring onl local analsis, this technique can be used with separate compilation since new classes added to the sstem cannot invalidate the laout of existing classes. herefore, the bidirectional laout scheme scales better to large-scale software development than other compact laout schemes requiring a global tpe analsis phase. A separate contribution of this paper is an efficient implementation of method signature refinement: a tpe ma compatibl modif the argument and return tpes of a method derived from its supertpes, in accordance with the usual subtping rules [ar84]. his feature is regrettabl missing from other staticall compiled languages like ++ or Modula-3 [Nel91]. he technique described here allows a class to refine superclass method signatures et retain fast method dispatch. he bidirectional object laout has been implemented for the programming language heta [DGLM95, LD 94, Me94], a separatel-compiled, staticalltped language which separates subtping and inheritance. heta allows a class to have an number of explicitl declared abstract supertpes, but onl a sin- 1

2 gle concrete superclass. his polic results from observations about the three common uses of multiple inheritance in programs, which are exploited b the bidirectional laout to generate more compact laouts: subtping An abstract tpe, or interface, combines several existing interfaces and extends them. he abstract tpe is a subtpe, and the extended interfaces are its supertpes. Elsewhere, this use is sometimes called interface inheritance among abstract classes. abstraction An implementation (a class) is isolated from the interface it implements, providing separate hierarchies for inheritance and subtping. As a result, a tpe need not expose implementation details for subtpe implementations to inherit them. inheritance A new implementation is formed b combining and extending existing implementations. he new implementation is a subclass, and the extended implementations are its superclasses. In addition to method code, a class contains instance variables and private methods that are not accessible outside the class and its subclasses. In this paper, the term inheritance is used exclusivel to mean implementation inheritance. he bidirectional laout supports the complex abstract-tpe/class hierarch shown in Figure 1 as efficientl as single-inheritance classes in ++. his common kind of hierarch has onl the subtping and abstraction uses of multiple inheritance. In the figure, the are classes, and the are abstract tpes. Arrows are used to denote the relations is a subtpe of, implements, and inherits from, depending on whether the two related entities are two abstract tpes, a class and an abstract tpe, or two classes. For example, 1 is the supertpe of 2, and 3 implements 3. Such hierarchies are common, because the provide a laer of abstraction that separates interface and implementation. Although subtping and inheritance are separate, the often develop in parallel. Separate hierarchies allow us to add new implementations of an of the tpes in the ladder 1 2 without being forced to inherit from existing classes. On the other hand, an implementation of one of these tpes is often useful in constructing an implementation of a subtpe (either direct or indirect), so inheritance often roughl mirrors Figure 1: A common kind of hierarch the subtpe hierarch. For lack of a better technique, ++ programmers use true multiple inheritance and other inefficient idioms to achieve this same separation. he bidirectional laout does better than current schemes because it implements subtping and abstraction differentl from true inheritance. It specificall optimizes lattice-like hierarchies like the one shown in Figure 1, where the tpes that a class and a superclass implement are in a parallel supertpe relationship. Even with the use of true multiple inheritance, the bidirectional laout never imposes a penalt compared to current ++ implementations. As in current ++ implementations, the laout of a class is determined using onl information about that class and the hierarch above it, with the result that new tpes and classes added to the sstem do not invalidate existing laouts. hanges to classes onl affect their subclasses, and changes to tpes onl affect their subtpes and the classes that implement the subtpes. Note that the supertpe relation must be explicitl declared rather than being implicitl inferred from method signatures. 2 Bidirectional Laout he bidirectional laout differs from the laouts used b man ++ implementations [Str87], though there are similarities. An object has a fixed memor laout, defined b its class. Figure 2 illustrates an object laout, which is divided in two parts (note that memor addresses increase downward within each box): A dispatch header, which is an arra of pointers to various dispatch vectors. Each dispatch vector is itself an arra of pointers to method code, indexed b small integers that are the method indices. he dispatch vector supports selector-table indexed (SI) dispatching [Ros88]. Each dispatch vector of 3 2

3 object dispatch vectors header object dispatch header s s object s header additional dispatch info. s header class dispatch vector Figure 2: Bidirectional object laout s s additional Figure 3: lass/superclass compatibilit an object specifies a different mapping from indices to methods. he last (bottom) dispatch vector, which is alwas present, is the class dispatch vector. It contains all the methods that can be called on the object. he other dispatch vectors are called tpe dispatch vectors. Dispatch vectors are shared b all objects of the particular class that owns them, but each object has its own cop of the dispatch header that points to them. Most objects have onl a single dispatch vector, so onl one word is consumed b the dispatch header. With the use of inheritance or subtping, the dispatch header laout grows backward in memor, if it grows at all. Fields, which contain mutable object data (usuall instance variables), are located after the dispatch header. When a class inherits code and from a superclass, the of the class are placed after the inherited, so the grow forward in memor with the use of inheritance. he bidirectional laout separates the and dispatch information of the object, whereas most ++ implementations intermingle them. One advantage of separating the dispatch information is that adjacent entries in the dispatch header can be merged into one entr b merging their corresponding dispatch vectors, using the rules described in Section 3. o ensure that method code inherited from the superclass need not be recompiled, the bidirectional laout makes the laout of a class compatible with that of its superclass. ompatibilit is achieved b nesting the superclass laout within that of the class, as shown in Figure 3. he dotted lines connect the laout of the superclass,, to the corresponding portion of the laout of the class,. he relationship of the two classes is indicated b the vertical arrow at the left of the figure. Because contains a portion whose laout is compatible with, inherited method code will work properl when passed a pointer to the portion of the object. In general, a laout whether of an object, a dispatch header, or just a dispatch vector is compatible with the corresponding superclass laout if the superclass laout is embedded in the subclass laout. Both abstract tpes and classes have dispatch header and dispatch vector laouts. lasses also provide dispatch header data that is copied into the beginning of objects of that class and contains pointers to the dispatch vectors shared b all objects of that class. An object reference is implemented b a pointer into the dispatch header. he dispatch vector indirectl referenced b the pointer is called the current dispatch vector. An object reference has some static, declared tpe, although the run-time tpe of the object ma be an of that tpe s subtpes. Regardless of the actual run-time object tpe, the method indices of the current dispatch vector agree with the method indices of the last dispatch vector of the static tpe s laout. Note that one dispatch vector ma contain methods for several tpes so long as the method indices do not conflict. 3

4 A 2.1 Example A B A B B object va object va vb methods: a1, a2 methods: a1,a2, b methods: a1,a2,c variables: va methods: a1,a2,b,c,d variables: va, vb dispatch vector c a1 a2 dispatch vector d c a1 a2 b Figure 4: Bidirectional laout example Figure 4 provides examples of bidirectional object laouts for two classes, and. hese classes implement tpes and respectivel. he methods and instance variables associated with each tpe or class are indicated in the diagram. For example, supports the methods a1 and a2 of its tpe, and adds a private method. It has one instance variable named va. he figure shows the laouts of objects and the dispatch vectors the point to. he dispatch headers for each of these classes contain a single dispatch vector, which is the class dispatch vector. Note that the object is compatible with the object, which is necessar because inherits from. 2.2 Method Indices his section describes method dispatch and the laout of dispatch vectors. A method call is implemented b fetching an element of the current dispatch vector, at a method index determined from the staticall declared tpe of the object. In the heta implementation, the dispatch vector contains pointers to method code, leading to the usual three-instruction assembl-language dispatch sequence for the MIPS architecture (most RIS architectures are similar), shown in Figure 5. ld t1, 0(a0) ; load dispatch vector ld t9, (i * wordsize)(t1) ; code pointer jalr ra, t9 ; jump to method Figure 5: SI dispatch on the MIPS In this code sample, the register a0 contains the object pointer. he value i is the method index. For an tpe and method M of that tpe, a method index i identifies the proper offset within the dispatch vector. For example, in Figure 4, the method index of the method b in tpe B is 2. Method indices are densel packed, which is desirable because dispatch vector space is used efficientl, ielding good cache performance. he indices of the methods in a tpe dispatch vector are in the range 0 1. In class dispatch vectors, some method indices are negative, and indices are in the range 1, for some and. For example, in Figure 4, 2 and 3 for. he use of negative method indices provides important flexibilit in constructing header laouts; the reason for this will become clear later. A tpe dispatch vector contains all the methods for tpes in a supertpe chain: a series of tpes 1, where is a supertpe of he first entries in the dispatch vector are for 1, then for 2, and so on. his ordering ensures that a subtpe dispatch vector is compatible with an supertpe in the chain. For example, the methods of the tpes 1 3 in Figure 1 could be placed in one dispatch vector,in that order. Methods are not duplicated in the dispatch vector, so the portion of the vector contains no methods that are derived from, where. herefore, the laout of the dispatch vector is uniquel defined b the sequence of tpes 1. For a subtpe dispatch vector to be compatible with a supertpe dispatch vector, the supertpe method indices must correspond to the same methods as in the subtpe. his condition implies that the supertpe dispatch vector must be embedded exactl at the start of the subtpe vector, since an offset would require remapping its method indices. he non-negative indices in a class dispatch vector are arranged as in a tpe dispatch vector. he 4

5 negative indices contain methods for a series of classes 1, where 1 inherits directl from. As in the non-negative portion, the 1 methods are closest to zero, and indices grow awa from zero. Private class methods are found onl in the negativel-indexed portion, but public methods derived from tpes ma also be there. For example, the class dispatch vector for in Figure 4 contains a negative portion with 1, 2 and a non-negative portion with 1, Object References An object reference is a pointer to a location in its dispatch header. As described earlier, the object header is an arra of pointers to different dispatch vectors. An object reference of tpe points indirectl to the appropriate dispatch vector for. he possible pointers to the object constitute multiple views of the object, each view corresponding to a tpe or tpes. When object method code is running, the reference to the receiver object self is alwas a class view: a pointer to the last dispatch vector, the class dispatch vector. his requirement makes instance variable accesses fast, because the class dispatch vector never moves relative to the. Each instance variable resides at a fixed offset from the self pointer in all class views, so the variable s value can be fetched b a single indexed load instruction. When a method is invoked on an object reference pointer that is does not point to the class dispatch vector, the pointer is adjusted b adding a small constant to it. his pointer bumping ensures that the method code receives the class view of the receiver. Because the actual class of the object is not known, the proper offset cannot be determined staticall a dnamic method must be used. o produce the offset dnamicall, dispatch vectors other than the class dispatch vector point to small trampoline procedures that bump the object pointer and then jump directl to the method code. he offset applied in the trampoline procedure is exactl the offset between the current dispatch vector and the class dispatch vector. A trampoline is shared b all objects of its class, so the total space required to store trampolines is relativel small. rampoline code for the MIPS R3000 is shown in Figure 6. In the figure, the register a0 contains the add a0, offset j method code ; offset reference ; jump to method Figure 6: A trampoline procedure on the MIPS receiver object reference. Because the code of Figure 5 jumps to these two instructions rather than directl to the method code, the trampoline adds an additional two-ccle penalt onto the SI dispatch cost for that processor. A similar or lesser cost should appl on most RIS architectures, since the trampoline jumps directl to the actual method code. he trampoline technique has been used b some ++ compilers (for example, the DE ++ compiler cxx, though not quite as compactl as the code of Figure 6), but seems not to be widel known. When an offset is not required, the trampoline is omitted, reducing the dispatch to just the three instructions of Figure 5. Object pointers also sometimes require bumping when a value is viewed as a supertpe of the current static tpe: for example, in an assignment to a variable of the supertpe, or when the value is passed as an argument to a method expecting a supertpe. When the dispatch vector of the supertpe is incompatible with the current dispatch vector, the pointer must be bumped to produce a valid supertpe view. he bump offset is a small constant that can be determined staticall. Adjacent dispatch vectors in the bidirectional laout often can be merged together to reduce the size of the dispatch header. Ideall, all the dispatch vectors are merged into the class dispatch vector, avoiding trampolines and tpe conversions. hus, compact object laouts also lead to faster code. 3 Laout Rules he following section presents the rules for constructing compact dispatch headers for the bidirectional laout. he goal of these rules is to generate compact laouts for classes that are part of tpical hierarchies. No object laout scheme can generate minimal laouts without global knowledge of the hierarch, but as these rules demonstrate, it is possible to do ver well with onl local information so long as the class hierarch conforms to expectations. Even when it does not, these rules do as well as or better than rules used b current 5

6 ++ compilers. Existing ++ compilers do not handle the hierarch of Figure 1 well. For each level of inheritance, the add an additional word of dispatch information, making multiple inheritance an inefficient wa to separate interfaces and implementations. Alternative techniques for separating inheritance and subtping are also hampered b extra overhead. B contrast, the rules in this paper handle hierarchies of this form with onl a single word of dispatch information. More complicated hierarchies involving multiple supertpes ma require more dispatch vectors for some classes, but the rules here are never less efficient than currentl used schemes. 3.1 Notation he construction rules for the bidirectional object laout are described here in a compact graphical notation. he rules are essentiall two-dimensional macros. his section briefl describes the notation, and provides some insight into the workings of object laout. he dispatch headers and dispatch vectors of an object can be thought of as a two-dimensional arra. he arra rows are dispatch vectors and the columns are individual methods. Each row generates a word of per-object space overhead in the dispatch header. Since different dispatch vectors of the object have different lengths, the rows of the arra are ragged. Each abstract tpe and class in the sstem has a distinct dispatch header laout. hese laouts are called tpe headers and class headers, respectivel. he laout of an abstract tpe or class is smbolized b placing a double box around it: X he height of the box corresponds to the number of dispatch vectors in it, and to the amount of space consumed b the dispatch header in each object. he width of the box is defined as the length of the last dispatch vector in the header. Both the number of dispatch vectors in the box, and the length of the last dispatch vector, are constants for a particular tpe or class. he box notation is useful because a tpe header is compatible with the dispatch header of each of the tpe s supertpes, and therefore must contain it at some offset. In the box notation, the box of the supertpe must be contained within that of the subtpe. An individual dispatch vector or a portion of one is denoted b a simple box. he notation 1, 2,..., n denotes a dispatch vector that contains methods for 1, n n Figure 7: A simple tpe header laout rule 2, and so on, in ascending method index order. Method pointers are not duplicated: for each, the methods included in the dispatch vector are those for which there is no method pointer in the 1 1 part. he vertical abutting of boxes means that the dispatch vectors of the lower box should be placed after the dispatch vectors of the upper box. he horizontal abutting of a dispatch header and a dispatch vector means that the last dispatch vector within should have appended to it. his notation now can be used to express a simple but inefficient rule for constructing tpe dispatch headers, shown in Figure 7. his is not the rule actuall used in the bidirectional laout; a better rule is presented later. Figure 7 is written as an inference rule. he antecedent, written above the line, indicates that the abstract tpe has direct supertpes 1 2. Supertpes are considered direct if the lie immediatel above in the tpe hierarch; indirect if the lie anwhere above. he triangles above the supertpes indicate that these tpes are part of an arbitrar tpe hierarch extending above them. he consequent, below the line, states that the laout for consists of the concatenated laouts for all the supertpes, except that the last dispatch vector has been extended to include the methods of that are not shared with 1. he mismatch in the heights of the boxes labeled 1 and is intentional: the box labeled represents a single dispatch vector, whereas the box labeled 1 represents a dispatch header that ma contain several dispatch vectors. he tpe 1 is called the primar supertpe, since its last dispatch vector is merged with that of. he tpes 2 are secondar supertpes. 6

7 Figure 8: Inefficient dispatch header Although this rule is not the actual bidirectionallaout rule, it has several instructive similarities. A reference to an object of tpe points to the last dispatch vector in the laout. onversion from an object of tpe to an of its direct supertpes requires onl the subtraction of a constant from the object pointer, which is zero in the case of 1, since it is embedded at the end. onversion to an indirect supertpe of requires the subtraction of a sum of these constant offsets, which is just a constant itself. alls to an methods of, given an object of static tpe, require onl the standard dispatch sequence, because all of the methods of are present in the last dispatch vector. 3.2 Merging he dispatch header rule of Section 3.1 works correctl but sometimes wastes space. For example, consider the tpe lattice shown in Figure 8. he leftmost supertpe at each branch is arbitraril considered to be primar, a convention that is followed throughout. he figure demonstrates the successive application of the rule in Section 3.1, producing the 6 laout shown, a three-word dispatch header. Obviousl, the first two dispatch vectors are compatible and can be merged, reducing the per-object overhead. Unfortunatel, the simple tpe rule does not allow this merge. he compatibilit arises because the laouts for 4 and 5 contain a common 3 piece, and can be merged. 3 is a secondar supertpe of 4, and is exposed in the 4 laout. Since 3 is in a single-supertpe chain above L x S and S m L S S w S. and no branches and merge(l, ) S. ma branch if S is on primar supertpe chain and merge(l, ) Figure 9: he two merge cases for 5, the 5 laout requires no more words of dispatch header space than does 3 s. he fact that the 5 header can be merged into the 4 header at some offset is expressed b the predicate: 5 4. Figure 9 provides the definition of. Given a tpe and an arbitrar laout, it shows the two cases in which the header can be merged into. he result of the merge is compatible with, and has the header embedded within it. In the figure, the blocks labeled w, x, and represent arbitrar pieces of dispatch header, possibl including multiple dispatch vectors. he block labeled m represents a part of a dispatch vector. hese conventions will be followed throughout. he first wa to satisf is if has a supertpe whose header is exactl the same size, and which is exposed in so that can be merged into the same place. For S to be exposed in means that nothing is appended to the end of its dispatch vectors in that laout, so that the block labeled m (the dispatch vector entries for methods of that are not methods of ) has nothing to collide with. hen, since is compatible with S, the merge result is compatible with. In order for the size of the and headers to x 7

8 ... 1 n Rule M1 merge() merge(... ) 1 n Rule 1: pe header laout be the same, and all its supertpes that are subtpes of must have onl one supertpe. In other words, there is a simple chain of supertpes leading up to. he second wa to satisf is to expose the header of at the beginning of, and embed it at the end of. Since S is exposed at the beginning of, and nothing is appended to its dispatch vectors, there is nothing for the w portion of to collide with, and the two laouts can be merged. In order for S to be located at the end of, and all its supertpes that are subtpes of must lie on a primar supertpe chain, since, as shown later, primar supertpes are alwas aligned with the last dispatch vector in the tpe header. here ma be branches in the supertpe structure over, which produce the w portion of the laout. Note that the dispatch vectors of that are shared with the embedded header for ma have methods appended to them, which is wh w extends to the right of S. 3.3 pe Header Rules he complete rule for tpe header laout is shown in Rule 1. Rule 1 looks like the simple tpe rule of Figure 7, except that it attempts to merge the supertpe headers using the function merge, defined b the rules in Figure 10. Like the rule of Figure 7, Rule 1 makes 1 the primar supertpe b aligning its header with that of. When a tpe has no supertpes, the result of the merge is considered to be empt, so the dispatch header for such a tpe contains just a single dispatch vector with the methods of, starting from index 0. With this interpretation, Rule 1 covers all cases for tpe header construction he merge function Rule M2 Rule M3 S. ma branch if x is empt,. S is on primar supertpe chain n merge(... ) merge( 1... n) 1 S merge(... ) 1 Rule M2 does not appl merge( 1... n) x x n Figure 10: Merge rules he function merge takes a list of tpes and produces a laout that merges the headers of all the tpes. here are three cases that the function considers, described in the rules M1, M2, and M3 of Figure 10. Rule M1 states the obvious base case: merging a single tpe header ields the tpe header itself. Rule M2 actuall performs a merge. he antecedent to M2 captures exactl the merge cases described in Figure 9, stating that n n merge 1 n 1 If x is non-empt, Rule M2 requires that there be no branches along the path from to, matching the antecedent to merge case 1. If x is empt, Rule M2 8

9 requires onl that be a primar supertpe of, matching the antecedent to merge case 2. he merge result from Rule M2 similarl matches the results of the two merge cases. In case 1, using Rule M2 to merge in does not increase the size of the tpe header. In case 2, the size of the tpe header increases, but onl b the size difference of n and S. If rules M1 and M2 fail, Rule M3 must be used: as in Figure 7, append n at the start of the previous merge. his rule increases the size of the tpe header b the height of n, so Rule M2 is alwas preferable when it can be applied. he rules for merge are complete, because M3 can alwas be applied in the case when M2 cannot pe Header Rule orrectness For the merge rules to be correct, tpe headers in a primar supertpe chain must be aligned with each other. his alignment is guaranteed because rules M2 and M3 keep the result of the previous merge aligned with the last word of the result merge. Also, embedded tpe headers must be located at a known offset from the end of the tpe header so that supertpe conversion works properl; Rule M1 clearl preserves this propert. Rule M3 keeps all embedded tpe headers in at the same offset, and all embedded tpe headers in are offset b the height of, which is a known constant. herefore, M3 preserves the propert. Rule M2 is more complex. learl, M2 keeps an embedded headers in S and at the same offset. Now, consider the embedded information in x. Rule M2 can satisf either of the merge cases of Figure 9. If it satisfies case 1, then n has the same height as S, so the dispatch information in x is located at the same offset in the resulting merge. If Rule M2 satisfies case 2, then n ma be larger than S, but x is empt. Inductivel, the known-offset propert is preserved b the combination of Rule 1 and the merge rules Supertpe Ordering he order in which the supertpes are merged is important, because it ma determine whether Rule M2 can be applied. he indices on the supertpes in Rule 1 can be assigned in an order that allows as much merging as possible. he current heta implementation does not attempt to find an optimal ordering, since the number of supertpes is usuall small. It successivel picks Rule 2: A non-inheriting class supertpes and places them in an ordered list for merge using the following heuristic. At each iteration, it preferentiall picks a supertpe whose header can be merged into the minimal number of unpicked supertpe headers. hus, it avoids adding a header until it has added an headers that it can be merged into. Usuall, there is a supertpe that cannot be merged into an other supertpe headers. It breaks ties b picking a supertpe that can be merged b Rule M2 into the laout of the currentl picked supertpes. he picked supertpe is appended to the end of the ordered list, and the process repeats. 3.4 lass Header Rules he advantages of the object laout described here are most apparent for a full class header. he kind of tpe lattice shown in Figure 8 is uncommon for abstract tpes, but similar hierarchies are frequent in a sstem with separate subtping and inheritance, as shown earlier in Figure 1. Merge optimizations like that in Section 3.3 are correspondingl more important, and are used b the bidirectional laout to produce compact class headers. In heta, a class implements either a single tpe or none; it inherits either from a single superclass or from none. lasses that do not implement a tpe are useful because the can be inherited without fear of damaging existing objects. he can also be used for private data structures within another implementation. here are several cases to be considered when constructing class headers, and the following sections will enumerate them and provide the construction rules Non-Inheriting lasses he simplest case to consider is a class that does not inherit from an superclass, shown in Rule 2. his rule optimizes the header of a non-inheriting class 9

10 S s s. ma branch if x is empt,.. S on primar supertpe chain. Rules 2 and 3 do not appl s s x S Rule 3: Merging tpe headers into class headers b making its class dispatch vector compatible with the tpe it implements,. he horizontal abutting of the two boxes, with on the right, indicates that the methods of that are not found in (the private methods) are prepended to the last tpe dispatch vector of. he indices of the methods do not change; the methods of are added with negative indices starting from -1. Note that if has onl single supertpes above it in the hierarch (a simple hierarch), then the whole class header for will consume onl a single word per object. If a class does not inherit from a superclass or implement an abstract tpe, Rule 2 also applies. he laout is considered to be empt, so the dispatch header of such a class contains a single dispatch vector with onl negativel-indexed methods Merging pe and lass Headers he ke to the efficienc of the bidirectional laout is the merging of tpe and class headers in tpe/class lattices, which is described b Rule 3. his rule computes the laout of a class that implements tpe and inherits from class. he header of must contain an exposed header that is compatible with. he header is formed b extending the class dispatch vector backward, and the embedded x Rule 4: Default class header rule header forward. he backward extension of the class dispatch vector makes the laout compatible with, and the forward extension makes it compatible with. Both extensions can affect the same dispatch vector, which is made possible because the backward extension of the class dispatch vector cannot collide with the forward extension of. As in the merge cases of Figure 9, the supertpe must either be on a simple supertpe chain above, or, if it is exposed at the start of s (i.e. x is empt), on a primar supertpe chain above. hus, Rule 3 is analogous to the earlier Rule M he Default Rule Rule 4 guarantees that the class header construction rules are complete. In the rule, is a class that implements the abstract tpe, and inherits from the class. he header for is formed b concatenating the headers of and, without merging. he methods of that are not alread in the the class dispatch vector of are prepended to the negative portion of the class dispatch vector. Rule 4 corresponds to merge Rule M3 and the simple tpe header laout polic of Figure 7: like a ++ laout, it tends to make the object dispatch overhead larger with each level of hierarch. When Rule 4 is applied to a class that does not implement an abstract tpe, the portion of the laout is considered to be empt. o produce the class header for, it just prepends the new methods. When is a supertpe of the tpe that implements, the heta implementation performs an optimization not shown in the diagram. Since is alread embedded in the header, there is no need to concatenate to s to create the header. he new methods are simpl prepended to the class dispatch vector. 10

11 3.4.4 ombining the Rules When Rule 3 applies, its advantage over Rule 4 is that it does not increase the size of the dispatch header with each level of hierarch. pe/class lattices like those depicted in Figure 1 require onl rules 1, 2, and 3, and all applications of rule 1 use merge rules M1 and M2. None of these rules cause the header to grow, so the class headers of all classes in a simple tpe/class lattice occup onl a single word. In fact, onl a single word of dispatch information is required for a class as long as the following two conditions are met: 1. No tpes in the hierarch above the class have multiple supertpes. 2. Either: (a) he tpe implemented b a class is a subtpe of the tpe implemented b its superclass, allowing merging b Rule 3, or (b) he tpe implemented b a class is a supertpe of the tpe implemented b its superclass, allowing merging b Rule 4 with optimization. his result is a significant improvement on existing techniques. Negative method indices allow smaller headers. Without them, reasonable merge schemes can be defined [Me94], but the size of headers in a tpe/class lattice is two words rather than one. he two dispatch vectors correspond to the negative and non-negative portions of the class dispatch vector lass Header Rule orrectness Rules 2 through 4 are both complete and correct, which again can be shown inductivel. For completeness, consider all possible classes. If the class does not implement a tpe, its header is defined b Rule 4. If the class does not inherit from a superclass, its header is defined b Rule 2. If the class both implements a tpe and inherits from a class, its header is defined b either Rule 3 or Rule 4, depending on whether merging is possible. herefore, all class headers are constructible. For correctness, embedded tpe and class headers must be found at known offsets from the class dispatch vector. Rules 2 and 4 clearl preserve this propert. Rule 3 operates almost identicall to merge rule M2, and the correctness arguments from Section again suffice Figure 11: Some complex tpes and classes Bidirectional Laout Usual ++ Laout Figure 12: Bidirectional and ++ laouts for Examples he success of these dispatch laout rules is illustrated b the laouts for the classes in the complex hierarch of Figure 11. Even though their laouts are computed with onl local knowledge of the hierarch, all the classes except 3 require onl a single dispatch vector. As shown in Figure 12, 3 has just two dispatch vectors in the bidirectional laout, whereas it has five in conventional laouts. he vertical center line in the dispatch vectors for the bidirectional laout represents the separation between the negative and positivelindexed methods. ontrast these header sizes with conventional ++ laouts: classes 1 through 4 have 2, 3, 5, and 2 dispatch vectors, respectivel. he disparit between the schemes increases with deeper hierarchies. 11

12 4 Multiple Inheritance he material so far has been in the context of heta, a language that does not allow multiple inheritance of code and instance variables. However, this section shows how to extend the bidirectional laout rules to support true multiple implementation inheritance. here are two approaches to supporting multiple inheritance, both of which generate alternate versions of method code inherited from some superclasses. 4.1 Recompilation If the language allows onl the instance variables of self to be accessed, multiple inheritance is easil implemented for a class. One of the superclasses is designated as the primar superclass; code is shared onl with this class. he primar superclass is handled exactl as described earlier for the superclass. he secondar superclasses are treated essentiall as if the were secondar supertpes, except that their are appended to the object laout along with the of the class. Since the secondar superclass do not begin after the class dispatch vector, the offset to them is different than in the superclass. A new version of secondar superclass methods is compiled or linked to use the correct offset for this class. Recompilation is eas, and produces compact objects with fast dispatching. However, it does not work if instance variables of objects other than self can be accessed, because the code accessing the variable cannot determine the proper field offset. Also, this solution causes some code duplication, since a class is recompiled for each distinct field offset used. 4.2 Dnamic Field Offsets A more flexible technique for supporting multiple inheritance is to determine the location of dnamicall. his technique produces at most two versions of method code, and allows access to instance variables of objects other than self. he location of the is provided b placing the correct field offset in the class dispatch vector, exactl as if the offset were a private method pointer. Man implementations of multiple inheritance have used intra-object pointers for this purpose; however, dnamic field offsets take no space per object, and are usuall just as fast. Since dispatch vectors are ld t1, 0(a0) ; load dispatch vector ld t2, (t1) ; load field offset add t3, a0, t2 ; start of Figure 13: Field access setup code shared, field offset loads are less likel than intra-object pointers to cause cache misses. he MIPS code to place the starting address of the into the register t3 is shown in Figure 13. Note that this computation ma be amortized over all field accesses to a particular object within a method call. Dnamic field offsets can be used to extend the recompilation scheme of Section 4.1 so that it supports accesses to instance variables of objects other than self. hese accesses use the dnamic field offset, since the correct field offset cannot be determined staticall. When instance variables of self are accessed, the correct offset is known, as before. A more space-efficient technique is for all code to access instance variables using the field offset. his approach has the advantage that all class methods can be inherited without recompilation; it has the disadvantage that accessing the instance variables of self requires the code of Figure 13. A reasonable compromise is to generate at most two versions of the class code. In both versions of the code, instance variables of objects other than self are accessed through the dnamic field offset. he versions differ in how the access the instance variables of self. he first, fast version is used for objects of the class itself and for subclasses that inherit from the class in a primar superclass chain. Since the field offset is known staticall, instance variables are accessed b an indexed load, as in the basic bidirectional scheme. he second, generic version accesses all instance variables through the dnamic field offset code of Figure 13, and is suitable for inheritance as a secondar superclass method. his second version is particularl appropriate for mix-in classes. 5 Method Signature Refinement he most general subtpe rules allow subtpes to widen argument tpes and narrow result tpes [ar84]. his process is sometimes called method signature refinement. Because implementing these rules efficientl is 12

13 difficult, separatel-compiled languages like ++ and Modula-3 have a more restrictive subtpe rule: the require that argument and return tpes sta the same in subtpe methods. However, the heta implementation demonstrates that refined method signatures can be efficientl implemented even in separatel-compiled languages. he subtpe rules are difficult to implement because objects have multiple views (see Section 2.3), a necessar feature of sstems with fast dispatch and separate compilation, such as heta or ++. Multiple views are also useful for treating primitive values (e.g., integers) as first-class objects in a sstem with a universal supertpe. o see wh multiple object views make signature refinement problematic, consider two abstract tpes and, where is a secondar supertpe of. An offset is required to convert between the and views. Suppose that the supertpe has a method identit that returns a, but that in, identit is declared to return a. his hierarch is sound, but creates practical implementation difficulties. Let x be a variable of declared tpe that actuall refers to a object. alling x.identit() ields a, but the caller expects a a different view of the object. he solution to the puzzle is straightforward: the compiler assigns multiple method indices to the method, one for ever tpe with a distinct signature for that method. Let be the method index of identit in. Because declares a new signature for identit, it introduces a new method index for calls that use the new signature. he compiler sends method calls to the appropriate method index based on the static tpe of the receiver object, so the presence of two distinct dispatch entries is never visible to the programmer. lasses that implement do not need to know about and onl have a entr, so the localit principle is preserved. lasses that implement are reall implementing the version of the method, so the entr points to the method code. he entr points to automaticall generated trampoline procedure, whose code bumps an arguments and calls the version of the method, then bumps the return values appropriatel. his trampoline makes the implementation of the method look as if it had the signature. On the MIPS R3000, the bumping of arguments and return values imposes a one ccle overhead per adjusted value, since Overhead Bidirectional able 1: heta librar object overheads all adjustments are constant additions. In man cases, a trampoline procedure would be required anwa to bump self, and the two trampolines can be merged. Note that a single dispatch vector can contain multiple versions of the same method, if no change of view is required among the tpes supporting the method, and its signature differs in them. his situation is not a problem, since the method index is chosen according to the static tpe of the receiver object. his technique applies to almost an multiple-view sstem with inheritance, such as the bidirectional object laout. It would also allow efficient implementation of refined method signatures in ++ if the language permitted. 6 Empirical Results he bidirectional laout efficientl handles hierarchies with separation of inheritance and subtping. wo class libraries were examined to determine how the bidirectional laout works in practice and whether existing code conforms to the assumptions that it is based on. 6.1 heta Librar he standard heta librar comprises 16 classes and 19 abstract tpes, and several other small libraries are under development. onsidering the two largest libraries, one implementing the OO7 database benchmark [DN93], and another implementing the Labbase database [RSG95], there are a total of 51 abstract tpes and 45 classes. able 1 shows the number of words of per-object dispatch overhead incurred b these classes with the bidirectional laout and with a standard ++ laout. Each entr in the table shows the number of classes that have a particular number of words of dispatch overhead. Of these classes, onl one requires more than a single dispatch vector with the bidirectional laout. It occupies a position in the hierarch ver similar to 3 in Figure 11, and has two dispatch 13

14 Overhead Bidirectional able 2: InterViews 3.1 object overheads vectors. he per-object space overhead is clearl lower for the bidirectional laout. Per-class space overhead is also less: the bidirectional laouts have a total of 46 dispatch vectors, compared to 73 in the ++ laout. he bidirectional dispatch vectors are larger on the average than the ++ dispatch vectors, but the do not repeat an information that is not also repeated b the ++ dispatch vectors. Since onl one trampoline routine needs to be generated for the bidirectional laout, total space usage is smaller. However, per-class space usage is less important than per-object space usage, since the total number of objects in an significant program is likel to be much larger than the total number of classes in use. 6.2 InterViews Librar An example of larger-scale object-oriented programming is the InterViews 3.1 toolkit [LV88], written in ++ with multiple inheritance. Including component libraries, it comprises about 426 public classes. It has evolved along with ++, so the code contains some historical artifacts: most of these classes are written in a single-inheritance stle with no separation of inheritance and subtping, and have onl a single word of dispatch information even with the ++ laout. Nevertheless, perusal of these classes reveals that the bidirectional laout would make man of them more efficient, using the multiple-inheritance extension of Section 4.2. he results are shown in able Space Usage With the bidirectional laout, ever class is as compact as in the laouts generated b the DE ++ compiler cxx (other compilers are similar), and 46 classes are more compact, some b as much as 4 words per object. Additional classes would be more compact if the uses of inheritance were virtual the current classes sacrifice inheritabilit for performance, so the results here are generous to ++. he total number of dispatch vectors is 465 for the bidirectional laout, and 537 for ++. Assuming that dispatch vectors all contain words, 66 trampoline procedures must be generated for the bidirectional scheme versus 111 for ++ (Non-trampoline techniques require even more space). he total space used b shared dispatch information in the two laout schemes is 597 words for the bidirectional laout and 759 words for the ++ laout. Again, per-object space overhead is likel to dominate the dispatch vector overhead in real programs InterViews Abstraction echniques he attempt to separate inheritance from subtping is a major source of inefficienc in the InterViews classes. About 30 classes (mostl members of the core InterViews librar) hide their implementation in a pointer to a private class. his mechanism is actuall less powerful than the separation provided b heta. he use of private implementation classes suggests that the hierarch of Figure 1 is common or at least desirable, as assumed. Unfortunatel, the private implementation pointer imposes even more space overhead than multiple inheritance. In addition to an extra object pointer at ever level of inheritance, the fragmentation of the object into two pieces imposes at least another word of overhead per object with commonl-used memor allocators. his fragmentation overhead has not been added to able 2. It is interesting to note that the InterViews classes use multiple inheritance mostl for abstraction. Among the ten uses of multiple inheritance in the public InterViews classes, there is onl one use of true multiple inheritance; the rest permit one class to implement several unrelated interfaces. For example, the classes for which the bidirectional laout generates a threeword dispatch header all implement three unrelated interfaces: Handler, MonoGlph, and Observer. In a separate-compilation environment where denselpacked method indices are compiled into the code, a three-word dispatch header is minimal for these classes. 14