CS 598 Scripting Languages Design and Implementation

14. Self Compilers

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]

First Self compiler

The compilation process

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

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.

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.

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.

The parser (cont.)

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.

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)

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:

Primitive inlining

• Primitive invocations can be • Inlined• Executed at compile

time for constant folding

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.

Message Splitting

Type prediction

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

Type prediction

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:

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

SELF-91

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)

Also on a Sun-4/260 (16.67 MHz Fujitsu processor)

SELF-91/C

4

4.7

5.26

Hölzle’s compiler (SELF-93)

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.

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.”

Performance on large benchmarks