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