Bifröst: letting Smalltalk loose

ESUG 2011 presentation

Transcript

1. Letting Smalltalk Loose Jorge Ressia www.scg.unibe.ch Tuesday, August 23, 11
2. Computer revolution has not happened yet Tuesday, August 23, 11
3. Computer revolution has not happened yet Alan Kay Keynote OOPSLA 1997 Tuesday, August 23, 11
4. improve previous ways of thinking Tuesday, August 23, 11
5. create new ways of thinking Tuesday, August 23, 11
6. Object-oriented Programming Tuesday, August 23, 11
7. Dynamic Tuesday, August 23, 11
8. We still go back to the source code Tuesday, August 23, 11
9. Debugging Tuesday, August 23, 11
10. } { } { } { } { } { Tuesday, August 23, 11
11. } { } { } { } { } { Tuesday, August 23, 11
12. } { } { } { } { } { Tuesday, August 23, 11
13. } { } { } { } { } { Tuesday, August 23, 11
14. } { } { } { } { } { Tuesday, August 23, 11
15. } { } { } { } { } { Tuesday, August 23, 11
16. } { } { } { } { } { Tuesday, August 23, 11
17. Profiling Tuesday, August 23, 11
18. Profile } { } { } { } { } { Domain-Sp CPU time profiling Mondrian [9] is an open and agile visualization engine. 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. 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 Tuesday, August 23, 11
19. Domain Profile } { } { } { } { } { CPU time profiling Mondrian [9] is an open and agile visualization engine. 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. 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/ Tuesday, August 23, 11
20. Mondrian Tuesday, August 23, 11
21. Tuesday, August 23, 11
22. System Complexity Lanza and Ducasse 2003 Tuesday, August 23, 11
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 great share of the CPU time, but it does not help in pinpointing Tuesday, August 23, 11
24. Which is the relationship? Domain-Specific Profiling 3 CPU time profiling 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, parser combinators, parsing expression grammars and packrat parsers to model grammars and parsers as objects that can be reconfigured dynamically [11]. ? Tuesday, August 23, 11
25. What is the problem? Tuesday, August 23, 11
26. Fixed Object Model Tuesday, August 23, 11
27. Most of the time this is good Tuesday, August 23, 11
28. Restricts what we can do Tuesday, August 23, 11
29. Time Tuesday, August 23, 11
30. Time is a very useful concept Tuesday, August 23, 11
31. considering it absolute limit us Tuesday, August 23, 11
32. absolute object model limit us Tuesday, August 23, 11
33. objects that evolve Tuesday, August 23, 11
34. Why? Tuesday, August 23, 11
35. Execution Reification Structure Evolution Profiling Debugging Tuesday, August 23, 11
36. Execution Reification Structure Evolution Profiling Debugging Tuesday, August 23, 11
37. } { } { } { } { } { Tuesday, August 23, 11
38. } { } { } { } { } { Tuesday, August 23, 11
39. When is the next state written? Tuesday, August 23, 11
40. Stop when the next message is received Tuesday, August 23, 11
41. Close the gap Tuesday, August 23, 11
42. Object Debugger Tuesday, August 23, 11
43. Execution Reification Structure Evolution Debugging Profiling Tuesday, August 23, 11
44. MetaSpy Tuesday, August 23, 11
45. MetaSpy TOOLS 2011 Bergel etal. Tuesday, August 23, 11
46. Mondrian Profiler Tuesday, August 23, 11
47. Tuesday, August 23, 11
48. System Complexity Lanza, Ducasse 2003 Tuesday, August 23, 11
49. Tuesday, August 23, 11
50. Profiling Structure Evolution Debugging Execution Reification Tuesday, August 23, 11
51. What if we do not know what to evolve? Tuesday, August 23, 11
52. Tuesday, August 23, 11
53. ? Tuesday, August 23, 11
54. Prisma Tuesday, August 23, 11
55. Scarring Tuesday, August 23, 11
56. Tuesday, August 23, 11
57. Tuesday, August 23, 11
58. Tuesday, August 23, 11
59. Tuesday, August 23, 11
60. Scanning Tuesday, August 23, 11
61. Tuesday, August 23, 11
62. Tuesday, August 23, 11
63. Tuesday, August 23, 11
64. Tuesday, August 23, 11
65. Tuesday, August 23, 11
66. Tuesday, August 23, 11
67. Tuesday, August 23, 11
68. Back in time Debugger Tuesday, August 23, 11
69. Back in time Debugger Object Flow Debugger Lienhard etal. ECOOP 2008 Tuesday, August 23, 11
70. Instance variable history Tuesday, August 23, 11
71. :Person field-write@t2 field-write@t3 init@t1 'Doe' person := Person new t1 ... name := 'Doe' t2 ... name := 'Smith' t3 'Smith' null predecessor predecessor value value value name name name Tuesday, August 23, 11
72. Profiling Execution Reification Debugging Structure Evolution Tuesday, August 23, 11
73. Talents scg.unibe.ch/research/talents Tuesday, August 23, 11
74. Talents scg.unibe.ch/research/talents IWST 2011 J. Ressia, T. Gîrba, O. Nierstrasz, F. Perin and L. Renggli Tuesday, August 23, 11
75. Dynamically composable units of reuse Tuesday, August 23, 11
76. moosetechnology.org Tuesday, August 23, 11
77. aFAMIXClass isTestClass Key instance-of message send lookup FAMIXEntity FAMIXType isTestClass FAMIXClass aFAMIXClass 1 2 3 self inheritsFrom: 'TestCase' MooseEntity ... Tuesday, August 23, 11
78. aFAMIXClass isTestClass FAMIXClass aFAMIXClass 1 2 4 aFAMIXClass inheritsFrom: 'TestCase' aJeeClassTalent Key instance-of message send lookup acquire 3 aJeeClassTalent talent isTestClass FAMIXEntity FAMIXType MooseEntity ... Tuesday, August 23, 11
79. •@ alias •- exclusion •, composition Operators Tuesday, August 23, 11
80. Flattening Tuesday, August 23, 11
81. Scoping Tuesday, August 23, 11
82. Evolution friendly Object Model Tuesday, August 23, 11
83. Tuesday, August 23, 11
84. Organize the Meta-level Tuesday, August 23, 11
85. Explicit Meta-objects Tuesday, August 23, 11
86. Object Meta-object Class Tuesday, August 23, 11
87. Object Meta-object Class Tuesday, August 23, 11
88. Evolved Object Meta-object Class Tuesday, August 23, 11
89. Object>>haltAtNextMessage | aMetaObject | aMetaObject := BFBehavioralMetaObject new. aMetaObject when: (BFMessageReceiveEvent new) do: [ self metaObject unbindFrom: self. TransparentBreakpoint signal ]. aMetaObject bindTo: self Tuesday, August 23, 11
90. We let Smalltalk loose Tuesday, August 23, 11
91. Object Debugger Prisma Subjectopia MetaSpy Talents Chameleon Tuesday, August 23, 11
92. scg.unibe.ch/jenkins/ Tuesday, August 23, 11
93. scg.unibe.ch/research/bifrost Tuesday, August 23, 11