Using Types to Analyze and Optimize ObjectOriented Programs By: Amer Diwan

1
Using Types to Analyze and Optimize
Object-Oriented ProgramsBy Amer Diwan

• Presented By Jess Martin, Noah Wallace, and Will
  von Rosenberg

2
Type-Based Alias Analysis (TBAA)

• Assumes type safe programming language, i.e.
  Modula-3.
• Comparative Analysis of Types and Subtypes
• Four Functions (Versions) of TBAA
• TypeDecl
• FieldTypeDecl
• SMTypeRefs
• SMFieldTypeRefs

3
TypeDecl

• Examine the declared type of AP and assume the AP
  may reference any object with the same declared
  type or subtype.

4
TypeDecl Example

• Class X
• Class Y X
• Class Z X
• Class D Y
• Class F Z

5
(No Transcript)
6
FieldTypeDecl

• Given AP1 and AP2 it returns true if AP1 and AP2
  are Aliases
• Modula-3 programs may take the addresses of
  memory locations in only two ways via the
  pass-by-reference parameter passing mechanism and
  the WITH statement.

7
FieldTypeDecl (contd)

• Identical APs always alias each other.
• Two qualified expressions may be aliases if they
  access the same field in potentially the same
  object.
• A pointer dereference may refer to the same
  location as a qualified subscripted expression
  only if their types are compatible and the
  program may take the address of the qualified or
  subscripted expression.
• In Modula-3, a subscripted expression cannot
  alias a qualified expression.
• Two subscripted expressions are aliases if they
  may subscript the same array. FieldTypeDecl
  ignores the actual subscripts.
• For all other cases of APs, including two pointer
  dereferences, FieldTypeDecl uses TypeDecl to
  determine aliases.

8
FieldTypeDecl

• Class P int a float b char c
• Class D int e float g char f P
• Int ra
• P and D?
• P.a and D.e?
• P.a and rai?
• P.f and rai?
• D and D?

9
SMTypeRefs

• Selective Type Merging
• Produces a TypeRefsTable

10
SMTypeRefs (contd)

• Initializes Group
• Examines all assignment statements, merges
  and if types are different.
• Filters infeasible aliases from Group, creating
  asymmetry.

11
SMTypeRefs (contd)
12
Applause
13
SMTypeRefs (contd)
14
SMTypeRefs (contd)
15
SMTypeRefs

• Class Blah
• Class PigletBlah
• Class PoohBlah
• Class PinkyPiglet
• Class BrainPiglet
• Class ScoobyPooh
• Class YogiPooh
• T New Blah
• P New Piglet
• F New Pooh
• T P
• P F
• T F
• What are the typeref tables for the three
  assignments?

16
SMFieldTypeRefs

• Fields Selectively Merge Type References
• We use SMTypeRefs instead of TypeDecl in the
  FieldTypeDecl algorithm
• Final version of TBAA

17
Using TBAA

• Redundant Load Elimination
• Loop invariant code motion
• Common subexpression elimination
• Resolving method invocation
• Type hierarchy analysis
• Intraprocedural type propagation
• Intraprocedural type propagation using TBAA
• Interprocedural type propagation
• Interprocedural type propagation using TBAA

18
Polymorphism through subtyping

• Polymorphic method invocation site calls more
  than one user procedure at run time.
• Monomorphic method invocation site calls only
  one user procedure at run time.
• A method is resolved if it is identified as being
  monomorphic.
• We wish to resolve all calls and replace them
  with direct calls.

19
Type Hierarchy Analysis

• Simply evaluates all possible overrides
  (overloads) for a particular function when passed
  a specific variable type.

20
Intraprocedural Type Propogation

• Breaks down types into type events
• Allocation
• Implicit and explicit type discrimination
• Assignment
• Complexity O(nv) where n is number of statements
  and v is the number of variables in the procedure

21
Intraprocedural Type Propogation using TBAA

• When it encounters a pointer dereference, it
  invokes SMFieldTypeRefs to get the set of
  locations referenced by the pointer deref
• Analysis discovers monomorphic uses of general
  data structures
• Complexity O(n(vNTNF)), where n is number of
  statements, v is number of variables, NT is
  number of types, and NF is number of fields

22
Interprocedural Type Propogation

• Call graph w/edges for each
• Builds work list
• Puts functions on work list if new information
• Merges parameter types
• Interprocedural Type Propogation using TBAA is
  the same implementation

23
Summary of analysis

• Type Hierarchy
• Intraprocedural Type Propagation
• Intraprocedural Type Propagation using TBAA
• Interprocedural Type Propagation
• Interprocedural Type Propagation using TBAA

24
Results

• Evaluates TBAA and Method resolution analyses.
• Static evaluation
• Dynamic evaluation
• Limit evaluation

25
TBAA Evaluation
26
Static Evaluation of TBAA
27
Static (contd)

• FieldType declare is more precise than TypeDecl.
• SMFieldTypeRefs offers little added precision.
• FieldTypeDecl finds more redundant loads than
  TypeDecl and SMFieldTypeRefs does not change by
  any significant amount

28
Static (contd)
29
Dynamic Evaluation of TBAA
30
Dynamic (contd)

• Two important points
• 1) a more precise alias analyses is not
  necessarily better it depends on how the analyses
  is used.
• 2) Static metrics are insufficient by themselves
  for evaluation

31
Limit Evaluation on TBAA

• Optimizations eliminate between 35 - 88 of the
  RL.
• Only 5 or fewer are redundant.
• Reveals that TBAA performs as well as any alias
  analysis could with the RLE and their benchmark.

32
Limit evaluation (contd)
33
Method Invocation
34
Static and Dynamic Evaluation

• Type Hierarchy analysis resolves many method
  invocations
• Intraprocedural type propagations resolves very
  few additional method invocations but removes
  NIL.
• Type propagation is useful for languages that
  have defined semantics such as Modula-3 or Java
• TBAA along with type propagation resolves most of
  the method invocation in the benchmarks.

35
(No Transcript)
36
Limit Evaluation (contd)
37
Limit Evaluation (contd)

• Explicit type tests and cloning combined with
  aggressive alias analyses may be able to resolve
  these method invocations.
• 4 sites are polymorphic but they comprise more
  than 80 of the total method invocations.