This document presents an aspect-oriented approach to improving productivity in dynamic languages through the use of typing concerns. It introduces type advice, which advises type information at specific join points to improve performance while maintaining productivity. Experiments show that applying type advice to a dynamic language like Groovy reduces compilation and execution times compared to the base language. This demonstrates that typing concerns can enhance the productivity of dynamic languages.

1. An Aspect-Oriented Approach
to Productivity Improvement
for a Dynamic Language
using Typing Concerns
Chanwit Kaewkasi
School of Computer Science
The University of Manchester
Supervisor: John R. Gurd
Advisor: Chris Kirkham

2. Motivation
● The High Productivity Computer Systems
(HPCS) program
● Productivity
● Aspect-oriented programming (AOP)
● Groovy
C. Kaewkasi 2

3. Motivation – HPCS
● The High Productivity Computer Systems
(HPCS) program.
● A program seeking for systems (languages +
platforms) that can double their productivity for
every 18 months.
● Focuses on both
● The development time, and
● The execution time.
C. Kaewkasi 3

4. Motivation – Productivity
● If compilation time is not concerned:
● If compilation time is concerned:
T(P) is the total time for solving problem P
with a certain programming language.
I(P) is the average development time.
C(P) is the average compilation time.
E(P) is the average execution time.
C. Kaewkasi 4

5. Motivation – Productivity
● Relative productivity between the base
language 0 and the new language L.
● P0 , problem P written in language 0.
● PL, problem P written in language L.
C. Kaewkasi 5

6. Motivation – AOP
● A programming paradigm
● Coping with crosscutting concerns
● Four major models:
● Pointcut-advice
● Inter-type declaration
● Class composition
● Traversal
C. Kaewkasi 6

7. Motivation – AOP (cont'd)
● Join point
● An abstract point in the flow of the execution of a
program.
● Aspect
● A modular unit encapsulating crosscutting concerns.
● Pointcut
● An expression for selecting, i.e. quantifying, join points.
● Advice codes
● A place (e.g., before, after, around) with
actions to perform at a certain join point.
C. Kaewkasi 7

8. Motivation – AOP (cont'd)
● Properties
● Quantification; a language has a feature for
selecting a set of join points with, e.g., an
expression.
● Invasiveness; this property allows execution of
aspect codes at a join point of the base program
without explicit declaration of that point.
C. Kaewkasi 8

9. Motivation – Groovy
● A dynamically typed language
● Type is optional
● Runs on Java Virtual Machines
● A direct migration path for Java
● Resembles the Java's syntax.
● Use the same environment, package system and run-
time.
● Use call site caching to improve performance
● A key place for typing concerns.
● Each call site corresponds to a call join point.
C. Kaewkasi 9

10. Hypothesis
Overall productivity of a computer program
written in a dynamic language, in terms of the
development time, the compilation time and the
execution time, can be improved by applying
a dynamic aspect-oriented typing technique.
C. Kaewkasi 10

11. Thesis questions
● What is the appropriate aspect-oriented technique?
● Ans: Type advice (for Typing concerns)
● How is the aspect-oriented technique used for
improving performance?
● Ans: Quantifying call join points, advising type to them.
When type of these points are obvious, traditional
optimisation can be applied.
● How to determine that the technique does improve
overall productivity?
● Ans: Relative productivity metric.
C. Kaewkasi 11

12. Typing concerns
● A kind of concerns found in dynamic languages
● To be precise, dynamically typed languages.
● Type-related
● Why only dynamic languages?
● Because type is not mandatory in this family of
languages.
● Type is strongly embodied as a part of statically
typed languages.
– Their compilers just won't allow us to separate typing.
C. Kaewkasi 12

13. Life cycle of a join point
C. Kaewkasi 13

14. Life cycle of a join point
C. Kaewkasi 14

15. Join point model of typing concerns
● Join point definition
● Traditional + the join point formation phase
● Identification of join point
● Pointcut-advice
def pointcut = pcall('T.x') & args(i)
● Specifying actions
● Type advice
typing(pointcut) { i >> int }
C. Kaewkasi 15

16. Join point model of typing concerns
● Join point definition
● Traditional + the join point formation phase
● Identification of join point
● Pointcut-advice
def pointcut = pcall('T.x') & args(i)
● Specifying actions
● Type advice
typing(pointcut) { i >> int }
C. Kaewkasi 16

17. Properties
● Quantification
● Inherited from the pointcut-advice model.
● Invasiveness
● Performance improvement is transparent to the
base programs.
C. Kaewkasi 17

18. FGV calculus
● A core object-oriented calculus based on
Featherweight Java.
● Objectives
● To study call site behaviours.
– Modelled invocation through call site objects.
– Leads to invention of type advice, and typing concerns.
● To present a proof of performance improvement.
– A dynamic call can be always replaced by a type advised
call, which is faster.
C. Kaewkasi 18

19. Reduction rules of FGV
C. Kaewkasi 19

20. Reduction rules of FGV (cont'd)
C. Kaewkasi 20

21. FGV program
C. Kaewkasi 21

22. Computation example
C. Kaewkasi 22

23. Theorem
Type advised call theorem:
A dynamic call (new C(e)).m(d) can be replaced
by a typed advised call C'.m'(new C(e), d) with a
smaller steps of reduction, for some class C and some
type advised class C'.
C. Kaewkasi 23

24. Theorem
Type advised call theorem:
A dynamic call (new C(e)).m(d) can be replaced
by a typed advised call C'.m'(new C(e), d) with a
smaller steps of reduction, for some class C and some
type advised class C'.
A dynamic call dispatched
through its call site object.
A class-level call dispatched directly.
In the implementation,
this class is run-time generated.
C. Kaewkasi 24

25. Reduction steps – Why faster?
● Dynamic call
(when the type advised class does not exist)
● R-Call → R-Invk → R-Field → R-Exec
● Dynamic call via call site replacement
(when the typed advised class exists)
● R-Call → R-Invk → R-Field → R-Repl
● Type advised call
● R-Sinvk
C. Kaewkasi 25

26. Reduction steps – Why faster?
● Dynamic call
(when the type advised class does not exist)
● R-Call → R-Invk → R-Field → R-Exec
● Dynamic call via call site replacement
(when the typed advised class exists)
● R-Call → R-Invk → R-Field → R-Repl
● Type advised call Replaceable
● R-Sinvk
C. Kaewkasi 26

27. Groovy AOP
● Pointcut-advice implementation
● Join point
● Aspect
● Pointcut
● Advice (before, after, and around)
● Type advice implementation
● Advice (typing)
C. Kaewkasi 27

28. Type Advice Engine
● Using Groovy AOP for matching join points
● If matched
● Generate a type advised class for the current
matched join point.
● Optimise the generated type advised class.
● Replace the current call join point, i.e. the current
call site, with the type advised call.
● Load the type advised class into the class loader.
● Re-define the current class via JVMTI.
● Wait and the program will be faster.
C. Kaewkasi 28

29. Relative productivity
● Compare between Java and Groovy with typing
concerns (GT).
C. Kaewkasi 29

30. Relative productivity (cont'd)
● Relative power is assumed to be 1 because
● The syntax of Groovy resembles that of Java.
● Its development environment, package, run-time
systems are the same.
● Only relative compilation and relative efficiency are
measured.
C. Kaewkasi 30

31. Benchmarks
● Fibonacci
● Heap sort
● Sieve (prime number computation)
● Fannkuch (pancake flipping)
● Running on
● Core2 Duo 3.0 GHz, Linux 2.6, JDK 1.6.0_b14
● P4 2.6 GHz, Windows 2000, JDK 1.6.0_b16
● Both running client and server JVM configurations
C. Kaewkasi 31

32. Compilation time measurement
● For Java
● Timing around com.sun.tools.javac.Main
● Benchmarks only.
● For Groovy with typing concerns
● Timing around Groovy's interactive tool
● Benchmarks and their typing aspects.
C. Kaewkasi 32

33. Compilation times in Milliseconds
C. Kaewkasi 33

34. Execution time measurement
● Both for Java and Groovy with typing concerns
● Run each benchmarks
● Measurement are divided into two parts, start-up
time and steady state.
C. Kaewkasi 34

35. Fibonacci – Core2 machine
C. Kaewkasi 35

36. Fibonacci – Core2 machine
C. Kaewkasi 36

37. Fibonacci – P4 machine
C. Kaewkasi 37

38. Fibonacci – P4 machine
C. Kaewkasi 38

39. Heap sort – Core2 machine
C. Kaewkasi 39

40. Heap sort – Core2 machine
C. Kaewkasi 40

41. Heap sort – P4 machine
C. Kaewkasi 41

42. Heap sort – P4 machine
C. Kaewkasi 42

43. Sieve – Core2 machine
C. Kaewkasi 43

44. Sieve – Core2 machine
C. Kaewkasi 44

45. Sieve – P4 machine
C. Kaewkasi 45

46. Sieve – P4 machine
C. Kaewkasi 46

47. Fannkuch – Core2 machine
C. Kaewkasi 47

48. Fannkuch – Core2 machine
C. Kaewkasi 48

49. Fannkuch – P4 machine
C. Kaewkasi 49

50. Fannkuch – P4 machine
C. Kaewkasi 50

51. Results
C. Kaewkasi 51

52. Results
C. Kaewkasi 52

53. Conclusion
● This thesis has introduced a new kind of type-
related aspect techniques, typing concerns.
● A technique of advising type information to a
certain join point is called type advice.
● This technique has been demonstrated to
improve performance of a dynamic language,
Groovy. While the technique still preserves its
productivity.
C. Kaewkasi 53

54. Other contributions
● Type Advice Engine
● A bytecode transformation module for advising type.
● Groovy AOP
● A dynamic AOP implementation.
● FGV calculus
● A core calculus language for studying call site
behaviour.
● The term relative compilation to relative
productivity metrics
C. Kaewkasi 54

55. Future work
● Generalisation of typing concerns to statically
typed languages?
● Implementation of Type Advice Engine:
● into virtual machines.
● near the level of virtual machines.
● Combination of typing and parallelisation
concerns?
● Further study of appropriate relative productivity
metrics for virtual machines.
C. Kaewkasi 55

56. Thank you
● Please feel free to ask questions.
C. Kaewkasi 56