Bifrost
-
Upload
esug -
Category
Technology
-
view
483 -
download
0
Transcript of Bifrost
Letting Smalltalk Loose
Jorge Ressia
www.scg.unibe.ch
Tuesday, August 23, 11
Computer revolution has not
happened yet
Tuesday, August 23, 11
Computer revolution has not
happened yetAlan Kay
Keynote OOPSLA 1997
Tuesday, August 23, 11
improve previous ways of thinking
Tuesday, August 23, 11
create new ways of thinking
Tuesday, August 23, 11
Object-orientedProgramming
Tuesday, August 23, 11
Dynamic
Tuesday, August 23, 11
We still go back to the source code
Tuesday, August 23, 11
Debugging
Tuesday, August 23, 11
}
{
}
{
}
{}
{
}
{
Tuesday, August 23, 11
}
{
}
{
}
{}
{
}
{
Tuesday, August 23, 11
}
{
}
{
}
{}
{
}
{
Tuesday, August 23, 11
}
{
}
{
}
{}
{
}
{
Tuesday, August 23, 11
}
{
}
{
}
{}
{
}
{
Tuesday, August 23, 11
}
{
}
{
}
{}
{
}
{
Tuesday, August 23, 11
}
{
}
{
}
{}
{
}
{
Tuesday, August 23, 11
Profiling
Tuesday, August 23, 11
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/
Tuesday, August 23, 11
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/
Tuesday, August 23, 11
Mondrian
Tuesday, August 23, 11
Tuesday, August 23, 11
System ComplexityLanza and Ducasse 2003
Tuesday, August 23, 11
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/
Tuesday, August 23, 11
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/
?
Tuesday, August 23, 11
What is the problem?
Tuesday, August 23, 11
Fixed Object Model
Tuesday, August 23, 11
Most of the time this is good
Tuesday, August 23, 11
Restricts what we can do
Tuesday, August 23, 11
Time
Tuesday, August 23, 11
Time is a very useful concept
Tuesday, August 23, 11
considering it absolute limit us
Tuesday, August 23, 11
absolute object model limit us
Tuesday, August 23, 11
objects that evolve
Tuesday, August 23, 11
Why?
Tuesday, August 23, 11
ExecutionReification
StructureEvolution
ProfilingDebugging
Tuesday, August 23, 11
ExecutionReification
StructureEvolution
ProfilingDebugging
Tuesday, August 23, 11
}
{
}
{
}
{}
{
}
{
Tuesday, August 23, 11
}
{
}
{
}
{}
{
}
{
Tuesday, August 23, 11
When is the next state written?
Tuesday, August 23, 11
Stop when the next message is received
Tuesday, August 23, 11
Close the gap
Tuesday, August 23, 11
Object Debugger
Tuesday, August 23, 11
ExecutionReification
StructureEvolution
Debugging Profiling
Tuesday, August 23, 11
MetaSpy
Tuesday, August 23, 11
MetaSpy
TOOLS 2011Bergel etal.
Tuesday, August 23, 11
Mondrian Profiler
Tuesday, August 23, 11
Tuesday, August 23, 11
System ComplexityLanza, Ducasse 2003
Tuesday, August 23, 11
Tuesday, August 23, 11
Profiling
StructureEvolution
Debugging
ExecutionReification
Tuesday, August 23, 11
What if we do not know what to evolve?
Tuesday, August 23, 11
Tuesday, August 23, 11
?Tuesday, August 23, 11
Prisma
Tuesday, August 23, 11
ScarringTuesday, August 23, 11
Tuesday, August 23, 11
Tuesday, August 23, 11
Tuesday, August 23, 11
Tuesday, August 23, 11
ScanningTuesday, August 23, 11
Tuesday, August 23, 11
Tuesday, August 23, 11
Tuesday, August 23, 11
Tuesday, August 23, 11
Tuesday, August 23, 11
Tuesday, August 23, 11
Tuesday, August 23, 11
Back in time Debugger
Tuesday, August 23, 11
Back in time Debugger
Object Flow Debugger
Lienhard etal. ECOOP 2008
Tuesday, August 23, 11
Instance variable history
Tuesday, August 23, 11
: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
Tuesday, August 23, 11
Profiling
ExecutionReification
Debugging
StructureEvolution
Tuesday, August 23, 11
Talents
scg.unibe.ch/research/talents
Tuesday, August 23, 11
Talents
scg.unibe.ch/research/talents
IWST 2011J. Ressia, T. Gîrba, O. Nierstrasz, F. Perin and
L. Renggli
Tuesday, August 23, 11
Dynamically composable units of
reuse
Tuesday, August 23, 11
moosetechnology.org
Tuesday, August 23, 11
aFAMIXClass isTestClass
Keyinstance-ofmessage sendlookup
FAMIXEntity
FAMIXType
isTestClassFAMIXClass
aFAMIXClass
1
2
3
self inheritsFrom: 'TestCase'
MooseEntity
...
Tuesday, August 23, 11
aFAMIXClass isTestClass
FAMIXClass
aFAMIXClass
1
2
4
aFAMIXClass inheritsFrom: 'TestCase'
aJeeClassTalent
Keyinstance-ofmessage sendlookupacquire
3aJeeClassTalent talent isTestClass
FAMIXEntity
FAMIXType
MooseEntity
...
Tuesday, August 23, 11
•@ alias
•- exclusion
•, composition
Operators
Tuesday, August 23, 11
Flattening
Tuesday, August 23, 11
Scoping
Tuesday, August 23, 11
Evolution friendly Object Model
Tuesday, August 23, 11
Tuesday, August 23, 11
Organize the Meta-level
Tuesday, August 23, 11
ExplicitMeta-objects
Tuesday, August 23, 11
Object
Meta-object
Class
Tuesday, August 23, 11
Object
Meta-object
Class
Tuesday, August 23, 11
Evolved Object
Meta-object
Class
Tuesday, August 23, 11
Object>>haltAtNextMessage | aMetaObject | aMetaObject := BFBehavioralMetaObject new. aMetaObject when: (BFMessageReceiveEvent new) do: [ self metaObject unbindFrom: self.
TransparentBreakpoint signal ]. aMetaObject bindTo: self
Tuesday, August 23, 11
We let Smalltalk loose
Tuesday, August 23, 11
Object Debugger Prisma
Subjectopia MetaSpy
Talents Chameleon
Tuesday, August 23, 11
scg.unibe.ch/jenkins/
Tuesday, August 23, 11
scg.unibe.ch/research/bifrost
Tuesday, August 23, 11