The document discusses profiling and debugging dynamic object-oriented programs. It describes how traditional profilers that use execution sampling do not provide enough information, such as which specific objects are causing performance issues. New techniques are proposed that track object identities and message passing to better pinpoint problems. These include domain-specific profilers for visualizations, back-in-time debuggers using object histories, and meta-level tools that can evolve and reconfigure objects and classes at runtime. The goal is to "let Smalltalk loose" by making its object model and meta-level more flexible and evolution-friendly to support advanced debugging and profiling.

1. Letting Smalltalk Loose
Jorge Ressia
www.scg.unibe.ch

2. Computer
revolution has not
happened yet

3. Computer
revolution has not
happened yet
Kay997
Alan PSLA 1
O
Keynote O

4. improve previous
ways of thinking

5. create new
ways of thinking

6. Object-oriented
Programming

7. Dynamic

8. We still go back to
the source code

9. Debugging

10. { {
{ {
}
}
}
} { }

11. { {
{ {
}
}
}
} { }

12. { {
{ {
}
}
}
} { }

13. { {
{ {
}
}
}
} { }

14. { {
{ {
}
}
}
} { }

15. { {
{ {
}
}
}
} { }

16. { {
{ {
}
}
}
} { }

17. Profiling

18. Domain-Sp
CPU time profiling
Mondrian [9] is an open and agile visualization engine.
visualization using a graph of (possibly nested) nodes an
Profile
a serious performance issue was raised1 . Tracking down
performance was not trivial. We first used a standard sam
Execution sampling approximates the time spent in an
by periodically stopping a program and recording the cu
under executions. Such a profiling technique is relatively
little impact on the overall execution. This sampling techn
all mainstream profilers, such as JProfiler, YourKit, xprof
MessageTally, the standard sampling-based profiler in P
tually describes the execution in terms of CPU consumpt
each method of Mondrian:
54.8% {11501ms} MOCanvas>>drawOn:
54.8% {11501ms} MORoot(MONode)>>displayOn:
30.9% {6485ms} MONode>>displayOn:
{ { | 18.1% {3799ms} MOEdge>>displayOn:
{ { ...
} | 8.4% {1763ms} MOEdge>>displayOn:
}
}
| | 8.0% {1679ms} MOStraightLineShape>>display:on:
| | 2.6% {546ms} FormCanvas>>line:to:width:color:
} { } ...
23.4% {4911ms} MOEdge>>displayOn:
...
We can observe that the virtual machine spent abou
the method displayOn: defined in the class MORoot. A ro
nested node that contains all the nodes of the edges of t
general profiling information says that rendering nodes a
great share of the CPU time, but it does not help in pin
and edges are responsible for the time spent. Not all grap
consume resources.
Traditional execution sampling profilers center their r
the execution stack and completely ignore the identity of th
the method call and its arguments. As a consequence, it
which objects cause the slowdown. For the example above,
says that we spent 30.9% in MONode>>displayOn: withou
were actually refreshed too often.
Coverage
PetitParser is a parsing framework combining ideas from
parser combinators, parsing expression grammars and pac
grammars and parsers as objects that can be reconfigured

19. CPU time profiling
Mondrian [9] is an open and agile visualization engine.
Profile
visualization using a graph of (possibly nested) nodes an
a serious performance issue was raised1 . Tracking down
performance was not trivial. We first used a standard sam
Execution sampling approximates the time spent in an
by periodically stopping a program and recording the cu
under executions. Such a profiling technique is relatively
little impact on the overall execution. This sampling techn
all mainstream profilers, such as JProfiler, YourKit, xprof
MessageTally, the standard sampling-based profiler in P
tually describes the execution in terms of CPU consumpt
each method of Mondrian:
54.8% {11501ms} MOCanvas>>drawOn:
54.8% {11501ms} MORoot(MONode)>>displayOn:
{ { 30.9% {6485ms} MONode>>displayOn:
{ { | 18.1% {3799ms} MOEdge>>displayOn:
} ...
}
} | 8.4% {1763ms} MOEdge>>displayOn:
| | 8.0% {1679ms} MOStraightLineShape>>display:on:
} { } | | 2.6% {546ms} FormCanvas>>line:to:width:color:
...
23.4% {4911ms} MOEdge>>displayOn:
...
We can observe that the virtual machine spent abou
the method displayOn: defined in the class MORoot. A ro
nested node that contains all the nodes of the edges of t
general profiling information says that rendering nodes a
great share of the CPU time, but it does not help in pin
and edges are responsible for the time spent. Not all grap
consume resources.
Traditional execution sampling profilers center their r
the execution stack and completely ignore the identity of th
the method call and its arguments. As a consequence, it
which objects cause the slowdown. For the example above,
says that we spent 30.9% in MONode>>displayOn: withou
were actually refreshed too often.
Domain
Coverage
PetitParser is a parsing framework combining ideas from
parser combinators, parsing expression grammars and pac
grammars and parsers as objects that can be reconfigured
1
http://forum.world.st/Mondrian-is-slow-next-step-tc
a2261116
2
http://www.pharo-project.org/

20. Mondrian

22. C omp lexity
stemand Ducasse 2003
Sy zaLan

23. little impact on the overall execution. This sampling technique is u
all mainstream profilers, such as JProfiler, YourKit, xprof [10], an
MessageTally, the standard sampling-based profiler in Pharo Sm
tually describes the execution in terms of CPU consumption and i
each method of Mondrian:
54.8% {11501ms} MOCanvas>>drawOn:
54.8% {11501ms} MORoot(MONode)>>displayOn:
30.9% {6485ms} MONode>>displayOn:
| 18.1% {3799ms} MOEdge>>displayOn:
...
| 8.4% {1763ms} MOEdge>>displayOn:
| | 8.0% {1679ms} MOStraightLineShape>>display:on:
| | 2.6% {546ms} FormCanvas>>line:to:width:color:
...
23.4% {4911ms} MOEdge>>displayOn:
...
We can observe that the virtual machine spent about 54% o
the method displayOn: defined in the class MORoot. A root is the
nested node that contains all the nodes of the edges of the visua
general profiling information says that rendering nodes and edge

24. Domain-Specific Profiling 3
CPU time profiling
Which is the relationship?
Mondrian [9] is an open and agile visualization engine. Mondrian describes a
visualization using a graph of (possibly nested) nodes and edges. In June 2010
a serious performance issue was raised1 . Tracking down the cause of the poor
performance was not trivial. We first used a standard sample-based profiler.
Execution sampling approximates the time spent in an application’s methods
by periodically stopping a program and recording the current set of methods
under executions. Such a profiling technique is relatively accurate since it has
little impact on the overall execution. This sampling technique is used by almost
all mainstream profilers, such as JProfiler, YourKit, xprof [10], and hprof.
MessageTally, the standard sampling-based profiler in Pharo Smalltalk2 , tex-
tually describes the execution in terms of CPU consumption and invocation for
each method of Mondrian:
54.8% {11501ms} MOCanvas>>drawOn:
54.8% {11501ms} MORoot(MONode)>>displayOn:
30.9% {6485ms} MONode>>displayOn:
?
| 18.1% {3799ms} MOEdge>>displayOn:
...
| 8.4% {1763ms} MOEdge>>displayOn:
| | 8.0% {1679ms} MOStraightLineShape>>display:on:
| | 2.6% {546ms} FormCanvas>>line:to:width:color:
...
23.4% {4911ms} MOEdge>>displayOn:
...
We can observe that the virtual machine spent about 54% of its time in
the method displayOn: defined in the class MORoot. A root is the unique non-
nested node that contains all the nodes of the edges of the visualization. This
general profiling information says that rendering nodes and edges consumes a
great share of the CPU time, but it does not help in pinpointing which nodes
and edges are responsible for the time spent. Not all graphical elements equally
consume resources.
Traditional execution sampling profilers center their result on the frames of
the execution stack and completely ignore the identity of the object that received
the method call and its arguments. As a consequence, it is hard to track down
which objects cause the slowdown. For the example above, the traditional profiler
says that we spent 30.9% in MONode>>displayOn: without saying which nodes
were actually refreshed too often.
Coverage
PetitParser is a parsing framework combining ideas from scannerless parsing,

25. What is the
problem?

26. Fixed Object Model

27. Most of the time
this is good

28. Restricts what we
can do

29. Time

30. Time is a very useful
concept

31. considering it
absolute limit us

32. absolute object
model limit us

33. objects that evolve

34. Why?

35. Debugging Profiling
Execution Structure
Reification Evolution

36. Debugging Profiling
Execution Structure
Reification Evolution

37. { {
{ {
}
}
}
} { }

38. { {
{ {
}
}
}
} { }

39. When is the next
state written?

40. Stop when the next
message is received

41. Close the gap

42. Object Debugger

43. Debugging Profiling
Execution Structure
Reification Evolution

44. MetaSpy

45. MetaSpy
OLS 2011
TO Ber gel etal.

46. Mondrian Profiler

48. C omp lexity
stema, Ducasse 2003
Sy anz L

50. Debugging Profiling
Execution Structure
Reification Evolution

51. What if we do not
know what to evolve?

53. ?

54. Prisma

55. Scarring

60. Scanning

68. Back in time
Debugger

69. Back in time
Debugger
Debu gger
w
Floal. ECOOP 2008
O b ject nhard e
t
Lie

70. Instance variable
history

71. name value
init@t1 null
predecessor
name value
:Person field-write@t2 'Doe'
predecessor
name
value
field-write@t3 'Smith'
person := Person new t1
...
name := 'Doe' t2
...
name := 'Smith' t3

72. Debugging Profiling
Execution Structure
Reification Evolution

73. Talents
scg.unibe.ch/research/talents

74. Talents
ST 2 011F. Perin and
IW ie rstrasz,
îr ba, O. N gli
J. Re ssia, T. G L. Reng
scg.unibe.ch/research/talents

75. Dynamically
composable units of
reuse

76. moosetechnology.org

77. MooseEntity
FAMIXEntity
...
FAMIXType
aFAMIXClass
isTestClass
2 FAMIXClass Key
instance-of
isTestClass
1 message send
lookup
aFAMIXClass self inheritsFrom: 'TestCase'
3

78. MooseEntity
FAMIXEntity
...
3
aJeeClassTalent
FAMIXType
talent isTestClass
aJeeClassTalent FAMIXClass
aFAMIXClass
2
inheritsFrom: 'TestCase'
4
aFAMIXClass Key
instance-of
1 message send
lookup
aFAMIXClass
acquire
isTestClass

79. Operators
• @ alias
• - exclusion
• , composition

80. Flattening

81. Scoping

82. Evolution friendly
Object Model

84. Organize the
Meta-level

85. Explicit
Meta-objects

86. Class
Meta-object
Object

87. Class
Meta-object
Object

88. Class
Meta-object
Evolved Object

89. Object>>haltAtNextMessage
| aMetaObject |
aMetaObject := BFBehavioralMetaObject new.
aMetaObject
when: (BFMessageReceiveEvent new)
do: [ self metaObject unbindFrom: self.
TransparentBreakpoint signal ].
aMetaObject bindTo: self

90. We let Smalltalk
loose

91. Object
Prisma
Debugger
Subjectopia MetaSpy
Talents Chameleon

92. scg.unibe.ch/jenkins/

93. scg.unibe.ch/research/bifrost