object centric reflection

Object-Centric Reflection

Jorge RessiaSoftware Composition Group

Thursday, August 30, 12

Profiling

Thursday, August 30, 12

Profiling:Is the activity of analyzing a program execution.

Thursday, August 30, 12

Profile

}

{

}

{

}

{}

{

}

{

Domain-Specific Profiling 3

CPU time profiling

Mondrian [9] is an open and agile visualization engine. Mondrian describes avisualization using a graph of (possibly nested) nodes and edges. In June 2010a serious performance issue was raised1. Tracking down the cause of the poorperformance was not trivial. We first used a standard sample-based profiler.

Execution sampling approximates the time spent in an application’s methodsby periodically stopping a program and recording the current set of methodsunder executions. Such a profiling technique is relatively accurate since it haslittle impact on the overall execution. This sampling technique is used by almostall 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 foreach 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 inthe 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. Thisgeneral profiling information says that rendering nodes and edges consumes agreat share of the CPU time, but it does not help in pinpointing which nodesand edges are responsible for the time spent. Not all graphical elements equallyconsume resources.

Traditional execution sampling profilers center their result on the frames ofthe execution stack and completely ignore the identity of the object that receivedthe method call and its arguments. As a consequence, it is hard to track downwhich objects cause the slowdown. For the example above, the traditional profilersays that we spent 30.9% in MONode>>displayOn: without saying which nodeswere actually refreshed too often.

Coverage

PetitParser is a parsing framework combining ideas from scannerless parsing,parser combinators, parsing expression grammars and packrat parsers to modelgrammars and parsers as objects that can be reconfigured dynamically [11].

1 http://forum.world.st/Mondrian-is-slow-next-step-tc2257050.html#a2261116

2 http://www.pharo-project.org/

Thursday, August 30, 12

Domain

Profile

}

{

}

{

}

{}

{

}

{

Domain-Specific Profiling 3

CPU time profiling

Mondrian [9] is an open and agile visualization engine. Mondrian describes avisualization using a graph of (possibly nested) nodes and edges. In June 2010a serious performance issue was raised1. Tracking down the cause of the poorperformance was not trivial. We first used a standard sample-based profiler.

Execution sampling approximates the time spent in an application’s methodsby periodically stopping a program and recording the current set of methodsunder executions. Such a profiling technique is relatively accurate since it haslittle impact on the overall execution. This sampling technique is used by almostall 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 foreach 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 inthe 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. Thisgeneral profiling information says that rendering nodes and edges consumes agreat share of the CPU time, but it does not help in pinpointing which nodesand edges are responsible for the time spent. Not all graphical elements equallyconsume resources.

Traditional execution sampling profilers center their result on the frames ofthe execution stack and completely ignore the identity of the object that receivedthe method call and its arguments. As a consequence, it is hard to track downwhich objects cause the slowdown. For the example above, the traditional profilersays that we spent 30.9% in MONode>>displayOn: without saying which nodeswere actually refreshed too often.

Coverage

PetitParser is a parsing framework combining ideas from scannerless parsing,parser combinators, parsing expression grammars and packrat parsers to modelgrammars and parsers as objects that can be reconfigured dynamically [11].

1 http://forum.world.st/Mondrian-is-slow-next-step-tc2257050.html#a2261116

2 http://www.pharo-project.org/

Thursday, August 30, 12

Mondrian

Thursday, August 30, 12

Thursday, August 30, 12

System ComplexityLanza and Ducasse 2003

Thursday, August 30, 12

Domain-Specific Profiling 3

CPU time profiling

Mondrian [9] is an open and agile visualization engine. Mondrian describes avisualization using a graph of (possibly nested) nodes and edges. In June 2010a serious performance issue was raised1. Tracking down the cause of the poorperformance was not trivial. We first used a standard sample-based profiler.

Execution sampling approximates the time spent in an application’s methodsby periodically stopping a program and recording the current set of methodsunder executions. Such a profiling technique is relatively accurate since it haslittle impact on the overall execution. This sampling technique is used by almostall 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 foreach 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 inthe 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. Thisgeneral profiling information says that rendering nodes and edges consumes agreat share of the CPU time, but it does not help in pinpointing which nodesand edges are responsible for the time spent. Not all graphical elements equallyconsume resources.

Traditional execution sampling profilers center their result on the frames ofthe execution stack and completely ignore the identity of the object that receivedthe method call and its arguments. As a consequence, it is hard to track downwhich objects cause the slowdown. For the example above, the traditional profilersays that we spent 30.9% in MONode>>displayOn: without saying which nodeswere actually refreshed too often.

Coverage

PetitParser is a parsing framework combining ideas from scannerless parsing,parser combinators, parsing expression grammars and packrat parsers to modelgrammars and parsers as objects that can be reconfigured dynamically [11].

1 http://forum.world.st/Mondrian-is-slow-next-step-tc2257050.html#a2261116

2 http://www.pharo-project.org/

Thursday, August 30, 12

Which is the relationship?Domain-Specific Profiling 3

CPU time profiling

Mondrian [9] is an open and agile visualization engine. Mondrian describes avisualization using a graph of (possibly nested) nodes and edges. In June 2010a serious performance issue was raised1. Tracking down the cause of the poorperformance was not trivial. We first used a standard sample-based profiler.

Execution sampling approximates the time spent in an application’s methodsby periodically stopping a program and recording the current set of methodsunder executions. Such a profiling technique is relatively accurate since it haslittle impact on the overall execution. This sampling technique is used by almostall 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 foreach 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 inthe 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. Thisgeneral profiling information says that rendering nodes and edges consumes agreat share of the CPU time, but it does not help in pinpointing which nodesand edges are responsible for the time spent. Not all graphical elements equallyconsume resources.

Traditional execution sampling profilers center their result on the frames ofthe execution stack and completely ignore the identity of the object that receivedthe method call and its arguments. As a consequence, it is hard to track downwhich objects cause the slowdown. For the example above, the traditional profilersays that we spent 30.9% in MONode>>displayOn: without saying which nodeswere actually refreshed too often.

Coverage

PetitParser is a parsing framework combining ideas from scannerless parsing,parser combinators, parsing expression grammars and packrat parsers to modelgrammars and parsers as objects that can be reconfigured dynamically [11].

1 http://forum.world.st/Mondrian-is-slow-next-step-tc2257050.html#a2261116

2 http://www.pharo-project.org/

?

Thursday, August 30, 12

Debugging

Thursday, August 30, 12

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

Thursday, August 30, 12

Mondrian

Thursday, August 30, 12

Thursday, August 30, 12

System ComplexityLanza and Ducasse 2003

Thursday, August 30, 12

Rendering

Thursday, August 30, 12

Shape and Nodes

Thursday, August 30, 12

Thursday, August 30, 12

Thursday, August 30, 12

How do we debug this?

Thursday, August 30, 12

Breakpoints

Thursday, August 30, 12

Conditional Breakpoints

Thursday, August 30, 12

}

{

}

{

}

{}

{

}

{

Thursday, August 30, 12

}

{

}

{

}

{}

{

}

{

Thursday, August 30, 12

Developer Questions

Thursday, August 30, 12

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)

Thursday, August 30, 12

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) Sillito etal.

Questions programmers ask during software

evolution tasks. 2008

Thursday, August 30, 12

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)

Thursday, August 30, 12

What is the problem?

Thursday, August 30, 12

Traditional Reflection

Thursday, August 30, 12

Domain-Specific Profiling 3

CPU time profiling

Mondrian [9] is an open and agile visualization engine. Mondrian describes avisualization using a graph of (possibly nested) nodes and edges. In June 2010a serious performance issue was raised1. Tracking down the cause of the poorperformance was not trivial. We first used a standard sample-based profiler.

Execution sampling approximates the time spent in an application’s methodsby periodically stopping a program and recording the current set of methodsunder executions. Such a profiling technique is relatively accurate since it haslittle impact on the overall execution. This sampling technique is used by almostall 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 foreach 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 inthe 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. Thisgeneral profiling information says that rendering nodes and edges consumes agreat share of the CPU time, but it does not help in pinpointing which nodesand edges are responsible for the time spent. Not all graphical elements equallyconsume resources.

Traditional execution sampling profilers center their result on the frames ofthe execution stack and completely ignore the identity of the object that receivedthe method call and its arguments. As a consequence, it is hard to track downwhich objects cause the slowdown. For the example above, the traditional profilersays that we spent 30.9% in MONode>>displayOn: without saying which nodeswere actually refreshed too often.

Coverage

PetitParser is a parsing framework combining ideas from scannerless parsing,parser combinators, parsing expression grammars and packrat parsers to modelgrammars and parsers as objects that can be reconfigured dynamically [11].

1 http://forum.world.st/Mondrian-is-slow-next-step-tc2257050.html#a2261116

2 http://www.pharo-project.org/

?

Profiling

Thursday, August 30, 12

?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)

Debugging

Thursday, August 30, 12

Object Paradox

Thursday, August 30, 12

Object-Centric Reflection

Thursday, August 30, 12

Thursday, August 30, 12

Organize the Meta-level

Thursday, August 30, 12

ExplicitMeta-objects

Thursday, August 30, 12

Object

Meta-object

Class

Thursday, August 30, 12

Object

Meta-object

Class

Thursday, August 30, 12

Evolved Object

Meta-object

Class

Thursday, August 30, 12

ExecutionReification

StructureEvolution

ProfilingDebugging

Thursday, August 30, 12

ExecutionReification

StructureEvolution

ProfilingDebugging

Thursday, August 30, 12

Object-Centric Debugging

Thursday, August 30, 12

Object-Centric Debugging

ICSE 2012J. Ressia, A, Bergel and O. Nierstrasz

Thursday, August 30, 12

}

{

}

{

}

{}

{

}

{

Thursday, August 30, 12

}

{

}

{

}

{}

{

}

{

Thursday, August 30, 12

}

{

}

{

}

{}

{

}

{

Thursday, August 30, 12

Thursday, August 30, 12

Thursday, August 30, 12

Thursday, August 30, 12

InstructionStream class>>on: InstructionStream class>>new InstructionStream>>initializeCompiledMethod>>initialPCInstructionStream>>method:pc:InstructionStream>>nextInstructionMessageCatcher class>>newInstructionStream>>interpretNextInstructionFor:...

on: new

initializemethod:pc:nextInstructioninterpretNextInstructionFor:...

step into, step over, resume

next message, next change

stack-centric debugging

object-centric debugging

...

centered on the InstructionStream class

centered on the InstructionStream object

next message, next change

Thursday, August 30, 12

Mondrian

Thursday, August 30, 12

Shape and Nodes

Thursday, August 30, 12

Thursday, August 30, 12

Thursday, August 30, 12

halt on object in call

Thursday, August 30, 12

Halt on next messageHalt on next message/s namedHalt on state changeHalt on state change namedHalt on next inherited messageHalt on next overloaded messageHalt on object/s in callHalt on next message from package

Thursday, August 30, 12

ExecutionReification

StructureEvolution

Debugging Profiling

Thursday, August 30, 12

MetaSpy

Thursday, August 30, 12

MetaSpy

TOOLS 2011Bergel etal.

Thursday, August 30, 12

Mondrian Profiler

Thursday, August 30, 12

Thursday, August 30, 12

System ComplexityLanza, Ducasse 2003

Thursday, August 30, 12

Thursday, August 30, 12

Profiling

StructureEvolution

Debugging

ExecutionReification

Thursday, August 30, 12

What if we do not know what to evolve?

Thursday, August 30, 12

Thursday, August 30, 12

?Thursday, August 30, 12

Prisma

Thursday, August 30, 12

Thursday, August 30, 12

Thursday, August 30, 12

Thursday, August 30, 12

Thursday, August 30, 12

Thursday, August 30, 12

Back in time Debugger

Thursday, August 30, 12

Back in time Debugger

Object Flow Debugger

Lienhard etal. ECOOP 2008

Thursday, August 30, 12

:Person field-write@t2

field-write@t3

init@t1

'Doe'

person := Person new t1...name := 'Doe' t2...name := 'Smith' t3

'Smith'

nullpredecessor

predecessor

value

value

value

name

name

name

Thursday, August 30, 12

Profiling

ExecutionReification

Debugging

StructureEvolution

Thursday, August 30, 12

Talents

scg.unibe.ch/research/talents

Thursday, August 30, 12

Talents

scg.unibe.ch/research/talents

IWST 2011J. Ressia, T. Gîrba, O. Nierstrasz, F. Perin and

L. Renggli

Thursday, August 30, 12

Dynamically composable units of

reuse

Thursday, August 30, 12

Streams

Thursday, August 30, 12

scg.unibe.ch/research/bifrost

Thursday, August 30, 12

Object-Centric

DebuggerPrisma

Subjectopia MetaSpy

Talents Chameleon

Thursday, August 30, 12

scg.unibe.ch/jenkins/

Thursday, August 30, 12

AlexandreBergel

MarcusDenker

StéphaneDucasse

OscarNierstrasz

LukasRenggli

OscarNierstrasz

OscarNierstrasz

OscarNierstrasz

TudorGîrba

FabrizioPerin

Thursday, August 30, 12

scg.unibe.ch/research/bifrost

Thursday, August 30, 12