1. CS 598 Scripting Languages Design and Implementation 14. Self Compilers

2. Self compilers We discuss three compilers described in the following documents: [ChUL89] Craig Chambers, David Ungar, Elgin Lee: An Efficient Implementation of SELF - a Dynamically-Typed Object-Oriented Language Based on Prototypes. OOPSLA 1989: 49-70 [SELF-89] [ChUn90] Craig Chambers, David Ungar: Iterative Type Analysis and Extended Message Splitting: Optimizing Dynamically-Typed Object-Oriented Programs. PLDI 1990: 150-164. [SELF-91] [Holz94] Urs Hölzle. Adaptive Optimization for SELF: Reconciling High Performance with Exploratory Programming. August 1994. [SELF-93]

3. First Self compiler

4. The compilation process All three compilers used Dynamic compilation: The compiler dynamically translates source methods on demand …”inspired by the Deutsch-Schiffman Smalltalk system”

5. The compiler Many potential inefficiencies shared with Smalltalk Cost of interpretation (fetch decode …) Dynamic dispatch This is particularly serious because of the many method invocations typical of OOLs Exacerbated in self where even variable accesses are implemented with messages Space inefficiencies of self due to absence of classes. It produces code that is 2 times faster than Smalltalk.

6. Maps From the implementation point of view, maps look much like classes, and achieve the same sorts of space savings for shared data. But maps are totally transparent at the SELF language level, simplifying the language and increasing expressive power by allowing objects to change their formats at will.

7. The parser Generates bytecode which contains 3 bits opcode and a 5-bit object array index (similar to the literal frame of Smalltalk) The 8 opcodes are to the right.

8. The parser (cont.)

9. Customized compilation A different compilation for each type of receiver of a method. For example, consider the method min: arg = ( < arg ifTrue: [self] False: [arg] ). If the expression i min: j is evaluated with i an integer, the compiler starts by building the flowgraph to the right. It then continues the compilation knowing that the receiver is an integer. The goal here is to optimize the < message. This is possible because inside the integer class, we know the type of self This technique is particularly useful in the case of instance variable accesses which are messages to self.

10. Message inlining If the type of the receiver is known at compile time, the compiler can perform the message lookup at compile-time and do one of the following: If the slot contains a method, the compiler will inline the body of the method at the call site, if the method is short enough and nonrecursive. If the slot contains a block value method, the compiler will inline the body of the block value method at the call site, if it is short enough. If after inlining there are no remaining uses of the block object, the compiler will eliminate the code to create the block at run-time. If the slot is a constant data slot, the compiler will replace the message send with the value of the slot (a constant known at compile-time). If the slot is an assignable data slot, the compiler will replace the message send with code to fetch the contents of the slot (e.g. a load instruction). If the slot is an assignment slot, the compiler will replace the message send with code to update the contents of the slot (e.g. a store instruction)

11. Message inlining (cont.) Consider the case of the < message < arg = ( _IntLTPrim: arg IfFail: [... ] ). Here, like in the case of all primitive implementations there is a failure block. Inlining will proceed as follows:

12. Primitive inlining Primitive invocations can be Inlined Executed at compile time for constant folding

13. Message splitting This strategy “a polymorphic message into several separate monomorphic messages. It avoids type tests by copying parts of the control flow graph” [Holz94]. Also useful for constant propagation.

14. Message Splitting

15. Type prediction Basically consist in introducing if statements testing type or value and the using message splitting for optimization.

16. Type prediction

17. Performance measurements Done on a Sun-4/260 (16.67 MHz Fujitsu processor). Compare to Smalltalk-80 system that incorporates the techniques described by Deutsch and Schiffman. Used the Stanford integer benchmarks, the Richards operating system simulation benchmarks, and these two codes:

18. SELF’ measures performance of rewritten benchmarks (those where the ration is within parenthesis were not rewritten)

19. SELF-91

20. Contributions Type inference Type information is used for message inlining Hence, type inference should help This includes an iterative procedure for loops. An initial assignment of types can lead to inlining. From the inlined version, new types are inferred. Repeat until convergence Extended splitting (see fig to the right)

21. Also on a Sun-4/260 (16.67 MHz Fujitsu processor) SELF-91/ C 4 4.7 5.26

22. Hölzle’s compiler (SELF-93)

23. Contributions Type Feedback, that allows any dynamically-dispatched call to be inlined. In our example implementation for SELF, type feedback reduces the call frequency by a factor of four and improves performance by 70% A recompilation system that dynamically reoptimizes the “hot spots” of an application. Polymorphic inline caching A debugging system that dynamically deoptimizes code to provide source-level debugging of globally optimized code.

25. Performance on Stanford Benchmarks Performance evaluation on “ a SPARC simulator based on the spa [76] and shade [34] tracing tools and the dinero cache simulator [66]. The simulator models the Cypress CY7C601 implementation of the SPARC architecture running at 40 MHz, i.e., the chip used in the SPARCstation-2 (SS-2) workstation.”

26. Performance on large benchmarks