Thesis defense

1. Object-Centric
Reflection
Unifying Reflection and Bringing it Back to
Objects
PhD Defense
Jorge Ressia
Advisor
Oscar Nierstrasz

2. Reflection

3. A reflective computational system is
capable of inspecting, manipulating and
altering its representation of itself.
Smith, 1982

4. Meta-level
Base-level

5. Structural
Reflection
Behavioral
Reflection

6. Reflection
Today

7. Reflection
Requirements

8. Mesage
Object

9. Message send
Message
Object

10. Partial Reflection

12. Selective
Reifications

14. Unanticipated
Changes

16. Runtime Integration

17. Meta-level
Composition

19. Scoped Reflection

21. Object-specific
Reflection

23. Profiling

24. Profiling:
Is the activity of analyzing a program
execution.

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

26. 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/

27. Mondrian

29. C omp lexity
stemand Ducasse 2003
Sy zaLan

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

31. CPU time profiling
Mondrian [9] is an open and agile visualization engine. Mondrian describes a
Which is the relationship?
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

32. Debugging

33. Debugging:
Is the process of interacting with a
running software system to test and
understand its current behavior.

34. Mondrian

36. C omp lexity
stemand Ducasse 2003
Sy zaLan

37. Rendering

38. Shape and Nodes

41. How do we debug
this?

42. Breakpoints

43. Conditional
Breakpoints

44. { {
{ {
}
}
}
} { }

45. { {
{ {
}
}
}
} { }

46. Developer Questions

47. When during the execution is this method called? (Q.13)
Where are instances of this class created? (Q.14)
Where is this variable or data structure being accessed?
(Q.15)
What are the values of the argument at runtime? (Q.19)
What data is being modified in this code? (Q.20)
How are these types or objects related? (Q.22)
How can data be passed to (or accessed at) this point
in the code? (Q.28)
What parts of this data structure are accessed in this
code? (Q.33)

48. When during the execution is this method called? (Q.13)
Where are instances of this class created? (Q.14)
Where is this variable or data structure being accessed?
(Q.15)
What are the values of the argument at runtime? (Q.19)
What data is being modified in this code? (Q.20)
How are these types or objects related? (Q.22)
How can data be passed to (or accessed at) this point
in the code? (Q.28)
What parts of this data structure are accessed in this
code? (Q.33) llito
Si etal. g softwar
e
ask durin
gr ammers s. 2008
Questi ons pro ution task
evol

49. Which is the relationship?
When during the execution is this method called? (Q.13)
?
Where are instances of this class created? (Q.14)
Where is this variable or data structure being accessed? (Q.15)
What are the values of the argument at runtime? (Q.19)
What data is being modified in this code? (Q.20)
How are these types or objects related? (Q.22)
How can data be passed to (or accessed at) this point in the code? (Q.28)
What parts of this data structure are accessed in this code? (Q.33)

50. What is the
problem?

51. Traditional
Reflection

52. 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
Profiling
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

53. Debugging
When during the execution is this method called? (Q.13)
?
Where are instances of this class created? (Q.14)
Where is this variable or data structure being accessed? (Q.15)
What are the values of the argument at runtime? (Q.19)
What data is being modified in this code? (Q.20)
How are these types or objects related? (Q.22)
How can data be passed to (or accessed at) this point in the code? (Q.28)
What parts of this data structure are accessed in this code? (Q.33)

54. Object Paradox

55. Object
Paradox

56. Object
Paradox

57. Object
Paradox
Reflection
Requirements

58. Object
Paradox
Reflection
Requirements

59. Object
Paradox
Unified Reflection
Uniform Requirements
Approach

60. Object
Paradox
Unified Reflection
Uniform Requirements
Approach

61. Thesis:
To overcome the object paradox while providing a
unified and uniform solution to the key reflection
requirements we need an object-centric reflective
system which targets specific objects as the central
reflection mechanism through explicit meta-objects.

62. Thesis:
To overcome the object paradox while providing a
unified and uniform solution to the key reflection
requirements we need an object-centric reflective
system which targets specific objects as the central
reflection mechanism through explicit meta-objects.

63. Thesis:
To overcome the object paradox while providing a
unified and uniform solution to the key reflection
requirements we need an object-centric reflective
system which targets specific objects as the central
reflection mechanism through explicit meta-objects.

64. Thesis:
To overcome the object paradox while providing a
unified and uniform solution to the key reflection
requirements we need an object-centric reflective
system which targets specific objects as the central
reflection mechanism through explicit meta-objects.

65. Thesis:
To overcome the object paradox while providing a
unified and uniform solution to the key reflection
requirements we need an object-centric reflective
system which targets specific objects as the central
reflection mechanism through explicit meta-objects.

66. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
56

67. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
57

68. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
58

69. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
59

70. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
60

71. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
61

72. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
62

73. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
63

74. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
64

75. Object-Centric
Reflection

76. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
66

77. 2010
time. Nierstrasz
@run
delsnggli,T. Gîrba and O
Mo e R
J. R essia, L.

78. Organize the
Meta-level

79. Explicit
Meta-objects

80. Object-Centric

81. Uniform
Solution

82. Class
Meta-object
Object

83. Class
Meta-object
Object

84. Class
Meta-object
Adapted Object

85. Runtime

86. AST adaptation

87. Source
Code
Syntactic
Analysis
Semantic
Analysis
AST Code
Manipulation Generation
Executable
Code

88. Class
Meta-object
Adapted Object

89. Structural
Reflection

90. Behavioral
Reflection

91. Composition

92. Meta-object
Meta-object

93. Meta-object
Meta-object
Composed
Meta-object

94. Any adaptation goes
through a meta-object

95. No implicit
Interactions

96. Reflection
Requirements

97. Partial Reflection

98. Selective
Reifications

99. Unanticipated
Changes

100. Runtime Integration

101. Meta-level
Composition

102. Scoped Reflection

103. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language

104. Development
94

105. Reuse

106. Mixins

108. Linear Composition

110. Single Composition

112. Traits

113. Class = Superclass + State + Traits +
Glue methods

114. Multiple
Composition

115. Flatten Composition

116. Problem

117. Streams

118. read
write
both

119. binary
character-based

120. memory
socket
database
file

121. Stream
PositionableStream NullStream
ReadStream WriteStream
ReadWriteStream TextStream LimitedWriteStream
RWBinaryOrTextStream

122. Explosion of classes

123. Dynamic
Composition

124. Talents
S PE 2 012
,
011Nierstrasz, F. Perin and
ST 2 .
IW ssia,T. Gîrba, O i
J. Re L . Renggl

125. Dynamically
composable units of
reuse

126. Meta-object

127. Special Composition

128. Operations

129. Define a method

130. readStreamTalent
defineMethodNamed: #isReadStream
performing: '^ true'.

131. Exclude a method

132. readStreamTalent
excludeMethodNamed: #isReadStream

133. Replace a method

134. readStreamTalent
replaceMethodNamed: #isReadStream
performing: '^ true'.

135. Read and Buffered
Stream

136. Composition
Operators

137. Composition

138. aStream := Stream new.
aStream acquire:
( readStreamTalent , bufferedStreamTalent ).

139. Alias

140. aStream := Stream new.
aStream acquire: readStreamTalent ,
( bufferedStreamTalent
@ {#isReadStream -> #isReadBufferedStream})

141. Exclusion

142. aStream := Stream new.
aStream acquire: readStreamTalent ,
(bufferedStreamTalent - #isReadStream).

143. Talents

144. Talents
S PE 2 012
,
011Nierstrasz, F. Perin and
ST 2 .
IW ssia,T. Gîrba, O i
J. Re L . Renggl

145. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
134

146. Behavioral
Reflection

147. Operational
Decomposition

148. Running System = Sequence of Events

149. Object
Object
Object
Object

150. Object
Debugger
Object
Feature
Analysis
Object
Profiler
Object

151. Object
Debugger
Object
Feature
Analysis
Object
Profiler
Object

152. Object
Debugger
Object
Feature
Analysis
Object
Profiler
Object

153. Chameleon

154. Object
Debugger
Object
Feature
Analysis
Object
Profiler
Object

155. Object
Debugger
Object
Feature
Analysis
Object
Profiler
Object

156. Object
Object
Object
Object

157. Object
Object
Object
Object

158. Meta-object
Object
Meta-object
Object
Meta-object
Object
Meta-object
Object

159. Meta-object
Object
Meta-object
Object
Meta-object
Object
Meta-object
Object

160. Definition of new
events

161. Adaptation on top of
these events

162. EventInstrumentor
reify: PurchaseEvent
onClass: Cart
selector: #purchase

163. ChameleonAnnouncer
subscribe: aDiscountChecker
to: PurchaseEvent

164. EventInstrumentor
reify: PointsPurchaseEvent
onObject: aCart
selector: #purchase

165. No source code
modification

166. Meta-object
Object
Meta-object
Object
Meta-object
Object
Meta-object
Object

167. Dynamically defined
events interface

168. Reification of the
adaptation

169. Chameleon

170. Rethink tools

171. Applications

172. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
157

173. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
158

174. Which is the relationship?
When during the execution is this method called? (Q.13)
?
Where are instances of this class created? (Q.14)
Where is this variable or data structure being accessed? (Q.15)
What are the values of the argument at runtime? (Q.19)
What data is being modified in this code? (Q.20)
How are these types or objects related? (Q.22)
How can data be passed to (or accessed at) this point in the code? (Q.28)
What parts of this data structure are accessed in this code? (Q.33)

175. { {
{ {
}
}
}
} { }

176. { {
{ {
}
}
}
} { }

177. Object-Centric
Debugging
2
201Nierstrasz
ICSE .
rgel and
O
J. Ressi a, A, Be

178. { {
{ {
}
}
}
} { }

179. { {
{ {
}
}
}
} { }

180. { {
{ {
}
}
}
} { }

181. What does it
mean?

182. intercepting
access to object-
specific runtime
state

183. monitoring
object-specific
interactions

184. supporting live
interaction

188. Mondrian

189. Shape and Nodes

192. halt on object in
call

193. InstructionStream

194. pc

195. How do we debug
this?

196. Debugging through operations
18 step in for first modification
30 operations for next modification

197. Setting breakpoints
31 method accessing the variable
9 assignments
pc setter is used by 5 intensively used classes

198. stack-centric debugging
InstructionStream class>>on:
InstructionStream class>>new
InstructionStream>>initialize
step into, CompiledMethod>>initialPC
step over, InstructionStream>>method:pc:
resume InstructionStream>>nextInstruction
MessageCatcher class>>new
InstructionStream>>interpretNextInstructionFor:
...
object-centric debugging
centered on centered on
the InstructionStream class the InstructionStream object
initialize
on:
next message, next message, method:pc:
new next change nextInstruction ...
next change
interpretNextInstructionFor:
...

199. Halt on next message
Halt on next message/s named
Halt on state change
Halt on state change named
Halt on next inherited message
Halt on next overloaded message
Halt on object/s in call
Halt on next message from
package

200. Object-Centric
Debugging
2
201Nierstrasz
ICSE .
rgel and
O
J. Ressi a, A, Be

201. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
183

202. 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/

203. 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,

204. Objects
Source Traditional
Code Profilers

205. Object
Objects
Profilers
Source Traditional
Code Profilers

206. MetaSpy
JOT 2 012
al.
Ressia et

207. Instrumenter Profiler

208. Domain Profilers
Domain
Object
Domain
Object
Domain
Object

209. Domain Profilers
Domain
Object
Domain
Object
Domain
Object
Instrumentation

210. Domain Profilers
Domain
Object
Domain
Object
Domain
Object
Instrumentation

211. Specify the Domain interests
Capture the runtime information
Present the results

212. Mondrian Profiler

214. MondrianProfiler>>setUp
self model root allNodes do: [ :node |
self
observeObject: node
selector: #displayOn:
do: [ ... counting ... ] ]

216. MetaSpy
JOT 2 012
al.
Ressia et

217. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
197

218. Live
Feature Analysis

219. Live
Feature Analysis
2010
dels l.
Mo Denker
eta

220. Software Feature:
A distinguishing characteristic of a
software item.
IE EE 829

221. Traces
{ {
{ { { {
} { {
} }
}
}
} }
}
} }
{
{

222. Traces
{ {
{ { { {
} { {
} }
}
}
} }
}
} }
{
{

223. Traces
{ {
{ { { {
} { {
} }
}
}
} }
}
} }
{
{

224. { {
{ {
}
}
}
}
} {
{ }

225. Paint AST nodes

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

229. ?

236. Execution
Reification

237. Reification of
Context

238. Reuse

239. Propagation

240. Dynamically
install and
uninstall

241. Thread Locality

242. Live
Feature Analysis

243. loginExecution := Execution new.
loginExecution
when: ASTNodeExecutionEvent
do: [ :node | node addFeatureAnnotation: #login ]

244. loginExecution
executeOn: [ WebServer new
loginAs: 'admin' password: 'pass' ]

245. printingExecution := Execution new.
printingExecution
when: ASTNodeExecutionEvent
do: [ :node | node addFeatureAnnotation: #printing ]

246. printingExecution
executeOn: [ WebServer new printStatusReport ]

250. Scoped
Reflection

251. Back in time
Debugger

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

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

255. Adapt reached
objects

256. Controlled
Impact

258. Thesis:
To overcome the object paradox while providing a
unified and uniform solution to the key reflection
requirements we need an object-centric reflective
system which targets specific objects as the central
reflection mechanism through explicit meta-objects.

259. Object
Paradox
Unified Reflection
Uniform Requirements
Approach

260. Object-Centric
Applications MetaSpy
Debugging
Talents Chameleon
Host Language
237

261. Performance

262. Live
Feature Analysis

263. Live
Feature Analysis
2010
dels l.
Mo Denker
eta

264. 179
classes

265. 1292
methods

266. adapted
all AST nodes

267. PRCommand >> context: aContext
context := aContext

268. 20%
slower

269. 35 times
slower

270. Implementation

272. AST adaptation

273. Source
Code
Syntactic
Analysis
Semantic
Analysis
AST Code
Manipulation Generation
Executable
Code

274. methodDict
Class MethodDictionary CompiledMethod
1 *
ReflectiveMethod

275. Object Key
run: #isPoint with: #() in: aPoint instance-of
message send
3 aMethodDictionary lookup
isPoint : aMetaObjectReflectiveMethod
Point isZero : aCompiledMethod
isPoint
run: #isPoint with: #() in: aPoint
2 4
aPoint aMetaObject aScopedMethodDictionary
isPoint : aReflectiveMethod
1 5
run: #isPoint with: #() in: aPoint
aPoint isPoint

276. Object Discovery

282. Feasibility

283. Dynamic Aspects

284. PBI

285. PBI
011 Eric Tanter
SD 2 d
AO alter Binder an
M oret, W
P hilippe

286. AOP

287. Dynamic Aspects

288. Per-object Aspects

289. Per-object Aspects
ftw. Eng.
SOF T So
SIG 003
tes 2llivan
No jan and Su
Ra

290. CaesarJ

291. CaesarJ
s AOS D 06
a nsac tionic etal.
Tr Arac

292. AspectScheme

293. AspectScheme
S CP 2 006amurthi.
n
an d Krish
n, Tucker,
Dutchy

294. AspectS

295. AspectS
6
200nza
O DAL a
and Co
st
H irschfeld

296. ALIA4J

297. ALIA4J
O LS 2 011kşit
TO Sewe, Mezini, and A
h,
Bockisc

298. ALIA4J AOP
Debugger

299. ALIA4J AOP
Debugger
2
201şit
AOSD h, and A
k
Yin, Bockisc

300. Related Work

301. Deployment
Strategies

302. Deployment
Strategies
SD 2 008
AO Eric Tanter

303. Scoping
Strategies

304. Scoping
Strategies
DLS 2009
er
Eric Tant

305. dynamic extent
propagation function
activation condition
adaptations

306. Future Work

307. Rethink the
debugger UI

308. Suicide Objects

309. Barbara Conradt, Programmed cell death

310. o bel 2 002ohn E. Sulston
N ne r and J
ydne y Bren
ob Ho rvitz, S
B
Barbara Conradt, Programmed cell death

312. Automatic Manual
Temporary Permanent
Referenced Unreferenced
Strong Weak

313. Cache

314. Strings

315. Dynamic Scoping

317. Undeployment
Conditions

318. Let objects decide

319. More Reflective
Applications

320. Talents

321. Scoped Talents

322. Dangerous?

323. I believe the argument that reflection is dangerous because it gives
programmers too much power is a specious one. Existing programming
languages already give clumsy programmers more than ample
opportunities to shoot themselves in the foot. I'll concede that reflective
systems allow the clumsy programmer to fire several rounds per second
into his foot, without reloading. Still, I'm confident that, as is the case
with features such as pointers, competent programmers will make
appropriate use of the power of reflection with care and skill. Potential
abuse by inept programmers should not justify depriving the
programming community of a potentially vital set of tools.
Brian Foote