Bifrost

698 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
698
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Bifrost

  1. 1. Letting Smalltalk Loose Jorge Ressia www.scg.unibe.chTuesday, August 23, 11
  2. 2. Computer revolution has not happened yetTuesday, August 23, 11
  3. 3. Computer revolution has not happened yet Kay997 Alan PSLA 1 O Keynote OTuesday, August 23, 11
  4. 4. improve previous ways of thinkingTuesday, August 23, 11
  5. 5. create new ways of thinkingTuesday, August 23, 11
  6. 6. Object-oriented ProgrammingTuesday, August 23, 11
  7. 7. DynamicTuesday, August 23, 11
  8. 8. We still go back to the source codeTuesday, August 23, 11
  9. 9. DebuggingTuesday, August 23, 11
  10. 10. { { { { } } } } { }Tuesday, August 23, 11
  11. 11. { { { { } } } } { }Tuesday, August 23, 11
  12. 12. { { { { } } } } { }Tuesday, August 23, 11
  13. 13. { { { { } } } } { }Tuesday, August 23, 11
  14. 14. { { { { } } } } { }Tuesday, August 23, 11
  15. 15. { { { { } } } } { }Tuesday, August 23, 11
  16. 16. { { { { } } } } { }Tuesday, August 23, 11
  17. 17. ProfilingTuesday, August 23, 11
  18. 18. 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 reconfiguredTuesday, August 23, 11 1 http://forum.world.st/Mondrian-is-slow-next-step-tc
  19. 19. 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/Tuesday, August 23, 11
  20. 20. MondrianTuesday, August 23, 11
  21. 21. Tuesday, August 23, 11
  22. 22. C omp lexity stemand Ducasse 2003 Sy zaLanTuesday, August 23, 11
  23. 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 pinpointingTuesday, August 23, 11
  24. 24. 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, parser combinators, parsing expression grammars and packrat parsers to modelTuesday, August 23,grammars and parsers as objects that can be reconfigured dynamically [11]. 11
  25. 25. What is the problem?Tuesday, August 23, 11
  26. 26. Fixed Object ModelTuesday, August 23, 11
  27. 27. Most of the time this is goodTuesday, August 23, 11
  28. 28. Restricts what we can doTuesday, August 23, 11
  29. 29. TimeTuesday, August 23, 11
  30. 30. Time is a very useful conceptTuesday, August 23, 11
  31. 31. considering it absolute limit usTuesday, August 23, 11
  32. 32. absolute object model limit usTuesday, August 23, 11
  33. 33. objects that evolveTuesday, August 23, 11
  34. 34. Why?Tuesday, August 23, 11
  35. 35. Debugging Profiling Execution Structure Reification EvolutionTuesday, August 23, 11
  36. 36. Debugging Profiling Execution Structure Reification EvolutionTuesday, August 23, 11
  37. 37. { { { { } } } } { }Tuesday, August 23, 11
  38. 38. { { { { } } } } { }Tuesday, August 23, 11
  39. 39. When is the next state written?Tuesday, August 23, 11
  40. 40. Stop when the next message is receivedTuesday, August 23, 11
  41. 41. Close the gapTuesday, August 23, 11
  42. 42. Object DebuggerTuesday, August 23, 11
  43. 43. Debugging Profiling Execution Structure Reification EvolutionTuesday, August 23, 11
  44. 44. MetaSpyTuesday, August 23, 11
  45. 45. MetaSpy OLS 2011 TO Ber gel etal.Tuesday, August 23, 11
  46. 46. Mondrian ProfilerTuesday, August 23, 11
  47. 47. Tuesday, August 23, 11
  48. 48. C omp lexity stema, Ducasse 2003 Sy anz LTuesday, August 23, 11
  49. 49. Tuesday, August 23, 11
  50. 50. Debugging Profiling Execution Structure Reification EvolutionTuesday, August 23, 11
  51. 51. What if we do not know what to evolve?Tuesday, August 23, 11
  52. 52. Tuesday, August 23, 11
  53. 53. ?Tuesday, August 23, 11
  54. 54. PrismaTuesday, August 23, 11
  55. 55. ScarringTuesday, August 23, 11
  56. 56. Tuesday, August 23, 11
  57. 57. Tuesday, August 23, 11
  58. 58. Tuesday, August 23, 11
  59. 59. Tuesday, August 23, 11
  60. 60. ScanningTuesday, August 23, 11
  61. 61. Tuesday, August 23, 11
  62. 62. Tuesday, August 23, 11
  63. 63. Tuesday, August 23, 11
  64. 64. Tuesday, August 23, 11
  65. 65. Tuesday, August 23, 11
  66. 66. Tuesday, August 23, 11
  67. 67. Tuesday, August 23, 11
  68. 68. Back in time DebuggerTuesday, August 23, 11
  69. 69. Back in time Debugger Debu gger w Floal. ECOOP 2008 O b ject nhard e t LieTuesday, August 23, 11
  70. 70. Instance variable historyTuesday, August 23, 11
  71. 71. 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 t3Tuesday, August 23, 11
  72. 72. Debugging Profiling Execution Structure Reification EvolutionTuesday, August 23, 11
  73. 73. Talents scg.unibe.ch/research/talentsTuesday, August 23, 11
  74. 74. Talents ST 2 011F. Perin and IW ie rstrasz, îr ba, O. N gli J. Re ssia, T. G L. Reng scg.unibe.ch/research/talentsTuesday, August 23, 11
  75. 75. Dynamically composable units of reuseTuesday, August 23, 11
  76. 76. moosetechnology.orgTuesday, August 23, 11
  77. 77. MooseEntity FAMIXEntity ... FAMIXTypeaFAMIXClass isTestClass 2 FAMIXClass Key instance-of isTestClass 1 message send lookup aFAMIXClass self inheritsFrom: TestCase 3Tuesday, August 23, 11
  78. 78. MooseEntity FAMIXEntity ... 3 aJeeClassTalent FAMIXType talent isTestClass aJeeClassTalent FAMIXClassaFAMIXClass 2 inheritsFrom: TestCase 4 aFAMIXClass Key instance-of 1 message send lookup aFAMIXClass acquire isTestClassTuesday, August 23, 11
  79. 79. Operators • @ alias • - exclusion • , compositionTuesday, August 23, 11
  80. 80. FlatteningTuesday, August 23, 11
  81. 81. ScopingTuesday, August 23, 11
  82. 82. Evolution friendly Object ModelTuesday, August 23, 11
  83. 83. Tuesday, August 23, 11
  84. 84. Organize the Meta-levelTuesday, August 23, 11
  85. 85. Explicit Meta-objectsTuesday, August 23, 11
  86. 86. Class Meta-object ObjectTuesday, August 23, 11
  87. 87. Class Meta-object ObjectTuesday, August 23, 11
  88. 88. Class Meta-object Evolved ObjectTuesday, August 23, 11
  89. 89. Object>>haltAtNextMessage | aMetaObject | aMetaObject := BFBehavioralMetaObject new. aMetaObject when: (BFMessageReceiveEvent new) do: [ self metaObject unbindFrom: self. TransparentBreakpoint signal ]. aMetaObject bindTo: selfTuesday, August 23, 11
  90. 90. We let Smalltalk looseTuesday, August 23, 11
  91. 91. Object Prisma Debugger Subjectopia MetaSpy Talents ChameleonTuesday, August 23, 11
  92. 92. scg.unibe.ch/jenkins/Tuesday, August 23, 11
  93. 93. scg.unibe.ch/research/bifrostTuesday, August 23, 11

×