Implementing Object-Oriented Languages. Implementing instance variable access. Implementing dynamic dispatching (virtual functions)

Transcription

1 Implementing Object-Oriented Languages Implementing instance variable access Ke features: inheritance (possibl multiple) subtping & subtpe polmorphism message passing, dnamic binding, run-time tpe testing Subtpe polmorphism is the ke problem support uniform representation of data (analogous to boing for polmorphic data) store the class of each object at a fied offset organize laout of data to make instance variable access and method lookup & invocation fast code compiled epecting an instance of a superclass still works if run on an instance of a subclass multiple inheritance complicates this perform static analsis to bound polmorphism perform transformations to reduce polmorphism Ke problem: subtpe polmorphism Solution: prefiing laout of subclass has laout of superclass as a prefi code that accesses a superclass will access the superclass part of an subclass properl, transparentl + access is just a load or store at a constant offset etends Point { // OK: subclass polmorphism Point p = new ColorPoint(3,4,Blue); // OK: and have same offsets in allpoint subclasses int manhattan_distance = p. + p.; Craig Chambers 232 CSE 501 Craig Chambers 233 CSE 501 Implementing dnamic dispatching (virtual functions) Virtual function s How to find the right method to invoke for a dnamicall dispatched messagercvr.message(arg1, )? Observation: in Option 3, all instances of a given class will have identical method addresses Option 1: search inheritance hierarch, starting from run-time class ofrcvr ver slow, penalizes deep inheritance hierarchies Option 2: use a hash can act like a cache on the front of Option 1 still significantl slower than a direct procedure call but used in earl Smalltalk sstems! Option 3: store method addresses in the receiver objects, as if the were instance variables each message/generic function declares an instance variable each inheriting object stores an address in that instance variable invocation = load + indirect jump! + good, constant-time invocation, independent of inheritance structure, overriding, much bigger objects Option 4: factor out class-invariant parts into shared object instance variables whose values are common across all instances of a class (e.g. method addresses) are moved out to a separate object historicall called a virtual function (vtbl) each instance contains a single pointer to the vtbl combine with (or replace) class pointer laout of subclass s vtbl has laout of superclass s vtbl as a prefi + dnamic dispatching is fast & constant-time but an etra load + no space cost in object aside from vtbl/class pointer Craig Chambers 234 CSE 501 Craig Chambers 235 CSE 501

2 Eample of virtual function s Multiple inheritance int distance2origin(); Point:: Point:: Problem: prefiing doesn t work with multiple inheritance etends Point { void reverse_video(); ColorPt:: ColorPt:: etends Point, ColoredThing { ColorPoint cp = new ColorPoint(3, 4, Blue); Point p = cp; // OK ColoredThing t = cp; // OK ColorPoint cp2 = new ColorPoint(p., p., t.); // breaks? Craig Chambers 236 CSE 501 Craig Chambers 237 CSE 501 Some solutions Another solution Option 1: stick with single inheritance [e.g. Smalltalk] some eamples reall benefit from MI Option 2: distinguish classes from interfaces [e.g. Java, C#] onl single inheritance below classes ifrcvr staticall of class tpe, then can eploit prefiing for its instance variable accesses and message sends disallow instance variables in interfaces no problems accessing them! onl messages to receivers of interface tpe are unresolved much smaller problem; can use e.g. hashing Option 3: compute offset of a field inrcvr b sendingrcvr a message [Cecil/Vorte] reduced problem to dnamic dispatching appl CHA etc. to optimize (all) dispatches for fields whose offsets never change, static binding + inlining reduces dispatches to constant Option 4: embedding + pointer shifting [C++] concatenate superclass laouts, etend with subclass data when upcasting to a superclass, shift pointer to point to where superclass is embedded downcasting does the reverse virtual function calls ma need to shift rcvr pointers "trampolines" ma get inserted + gets back to constant-time access in most cases ver complicated, lots of little details some things (e.g. casting) ma now have run-time cost does poorl if using "virtual base classes", i.e., diamondshaped inheritance hierarchies some sensible programs now disallowed e.g. casting through void*, downcasting from virtual base class interior pointers ma complicate GC, equalit testing, debugging, etc. Craig Chambers 238 CSE 501 Craig Chambers 239 CSE 501

3 Eample etends Point, ColoredThing { ColorPoint cp = new ColorPoint(3, 4, Blue); Point p = cp; // OK ColoredThing t = cp; // OK: adds 8 tocp // now this works: ColorPoint cp2 = new ColorPoint(p., p., t.); cp // this works, too: ColorPoint cp3 = (ColorPoint) t; // subtracts 8 fromt p t Eample of virtual function s int (); p t void reverse_video(); etends Point, ColoredThing { ColorPt:: this = this + 12; jump CT::; Craig Chambers 240 CSE 501 Craig Chambers 241 CSE 501 Limitations of -based techniques Dnamic -based implementations Table-based techniques onl work well when: have static tpe information to use to map message/ instance variable names to offsets in s/objects not true in dnamicall tped languages cannot etend classes with new operations ecept via subclassing not true in languages with open classes (e.g. MultiJava [Clifton et al. 00]) or multiple dispatching (e.g. CLOS, Dlan, Cecil) cannot modif classes dnamicall not true in full reflective languages (e.g. Smalltalk, Self, CLOS) Standard implementation: global hash in runtime sstem indeed b class msg filled dnamicall as program runs can be flushed after reflective operations + reasonable space cost + incremental fair average-case dispatch time, poor worst-case time Refinement: hash per message name each call site knows staticall which to consult + faster dispatching memor loads and indirect jumps are inepensive ma not be true with heavil pipelined hardware Craig Chambers 242 CSE 501 Craig Chambers 243 CSE 501

4 Inline caching Eample of inline caching Give each dnamicall-dispatched call site its own small method lookup cache + call site knows its message name + cache is isolated from other call sites Trick: use machine call instruction itself as a one-element cache initiall: call runtime sstem slookup routine Lookup routine patches call instruction to branch to invoked method record receiver class net time through, jump directl to epected target method method checks whether current receiver class is same as last receiver class if so, then cache hit (90-95% frequenc, for Smalltalk) if not, then calllookup and rebind cache + fast dispatch sequence if cache hit ( 4 instructions plus call) + hardware call prefetching works well eploits self-modifing code low performance if not a cache hit Initiall: msg: class: After caching target method: msg: class: CPt ColorPoint::() if cache.class self.class then regular code [Deutsch & Schiffman 84] Craig Chambers 244 CSE 501 Craig Chambers 245 CSE 501 Polmorphic inline caching (PIC) Eample of polmorphic inline caching Idea: support a multi-element cache b generating a call-site-specific dispatcher stub + fast dispatching even if several classes are common still slow performance if man classes equall common some space cost Foreshadowing: dispatching stubs record dnamic profile data of which receiver classes occur at which call sites [Hölzle et al. 91] After a few receiver classes: msg: switch (self.class) { case ColorPt: case ColorPt3D: case Point: default: ColorPt::() Point::() Craig Chambers 246 CSE 501 Craig Chambers 247 CSE 501

5 Implementing the dispatcher stub switch Handling multiple dispatching In original PIC design, switch implemented with a linear chain of class identit tests Alternativel, can implement with a binar search, eploiting ordering of integer class IDs or addresses + avoid worst-case behavior of long linear searches + a single test can direct man classes to same target method requires global knowledge to construct dispatchers In traditional compilers, switch implemented with a jump, akin to C++ dispatch s Can blend -based lookups, linear search, and binar search [Chambers & Chen 99] eploit available static analsis of possible receiver classes, profile information of likel receiver classes construct dispatcher best balancing epected dispatching speed against dispatch space cost Languages with multimethods (e.g. CLOS, Dlan, Cecil) allow methods to dispatch on the run-time classes of an of the arguments call sites do not know staticall which arguments ma be dispatched upon Implementation schemes: hash indeed b N kes [Kiczales & Rodriguez 89] N-deep tree of hash s, each indeed b 1 ke [Dussud 89] can stop dispatching at an subtree if all remaining arguments undispatched N-deep DAG of 1-ke dispatches [Chen & Turau 94, Chambers & Chen 99] compressed N+1-dimensional dispatch [Amiel et al. 94, Pang et al. 99] Probabl more efficient to support multimethods directl than if simulated with double-dispatching [Ingalls 86] or visitor pattern [Gamma et al. 95] Craig Chambers 248 CSE 501 Craig Chambers 249 CSE 501