• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Object-Centric Reflection - Thesis Defense
 

Object-Centric Reflection - Thesis Defense

on

  • 1,103 views

Thesis defense

Thesis defense

Statistics

Views

Total Views
1,103
Views on SlideShare
1,050
Embed Views
53

Actions

Likes
0
Downloads
4
Comments
0

2 Embeds 53

https://twitter.com 52
https://si0.twimg.com 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Reflected on reflection\nThinking it inside out.\nreinvented reflection.\n
  • \n
  • \n
  • A reflective system can be divided into two levels: the base level, which is concerned with the application domain, and the meta-level, which encompasses the self-representation.\n\n
  • A reflective system can be divided into two levels: the base level, which is concerned with the application domain, and the meta-level, which encompasses the self-representation.\nThese levels are causally connected\n\n\n
  • \n
  • Behavioral reflection is concerned with the manipulation of the abstractions which govern the execution of a program.\n\n\n
  • \n
  • \n
  • \n
  • There has been a lot of work in this domain.\nThis is a summary of the requirements\n
  • There has been a lot of work in this domain.\nThis is a summary of the requirements\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • refers to a meta-environment that runs at the same level as the application code, i.e., not in the interpreter of the host language \n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Code profilers commonly employ execution sampling as the way to obtain dynamic run-time information\n
  • \n
  • is a framework for drawing graphs\n
  • \n
  • \n
  • What is the relationship between this and the domain? picture again\n
  • \n
  • \n
  • is a framework for drawing graphs\n
  • width = the number of attributes of the class\nheight = the number of methods of the class\ncolor = the number of lines of code of the class\n\n
  • \n
  • double dispatch\n
  • one of the nodes was not correctly rendered\n
  • \n
  • \n
  • \n
  • We have to go back to the code\n
  • Which questions do these debuggers try to answer?\n
  • Sillito\n
  • \n
  • Which questions do these debuggers try to answer?\n
  • \n
  • \n
  • \n
  • although object-oriented developers are supposed to think in terms of objects, the tools and environments they use mostly prevent this.\n\nReflective systems prioritizing static mechanisms over object reflection present a gap between the user needs and what the reflective systems provides. Thus, the user is less efficient since he has to introduce ad hoc changes to steer the reflective systems to solve its object-specific needs\n\n\n
  • requirements +\nobject paradox +\nunified and uniform\n\nsolution object-centric with meta-objects\n\nexplicit object-centric meta-objects.\n
  • requirements +\nobject paradox +\nunified and uniform\n\nsolution object-centric with meta-objects\n\nexplicit object-centric meta-objects.\n
  • requirements +\nobject paradox +\nunified and uniform\n\nsolution object-centric with meta-objects\n\nexplicit object-centric meta-objects.\n
  • requirements +\nobject paradox +\nunified and uniform\n\nsolution object-centric with meta-objects\n\nexplicit object-centric meta-objects.\n
  • requirements +\nobject paradox +\nunified and uniform\n\nsolution object-centric with meta-objects\n\nexplicit object-centric meta-objects.\n
  • \n
  • \n
  • unified: the approach should solve all the requirements\nuniform: the approach should do this in a unique way, not having special cases that need to be handled differently from the rest.\n
  • \n
  • \n
  • In the remainder of this presentation I am going to show how to address these issues.\nThe graphic displays the architecture of the Bifröst System.\nIt also serves as an agenda for the remainder of this presentation. \n\nExplain what we are going to do in each part.\n\n1.- we will explain the core of ocr\n2.- we will analyze how development itself is changed with this new approach\n3.- we will analyze the impact of ocr on en user applications, does it have a meaningful impact, why should I care about this.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • We see that there are many different ways of doing reflection, adaptation, instrumentation, many are low level.\nAnd the ones that are highly flexible cannot break free from the limitations of the language.\n
  • Adaptation semantic abstraction for composing meta-level structure and behavior.\n
  • The meta-objects can be applied and deapplied at any time.\n
  • There is no special case, there is no side path, everything works by attaching meta-objects to objects.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • No change happens without going through them. No implicit interactions!!!\n\nThis makes reflection explicit.\n
  • \n
  • There has been a lot of work in this domain.\nThis is a summary of the requirements\n
  • \n
  • \n
  • \n
  • refers to a meta-environment that runs at the same level as the application code, i.e., not in the interpreter of the host language \n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Since My Rectangle is a composition, I cannot access the behavior in MColor or MBorder exclusively.\nMixins have to be applied one at a time.\n
  • \n\n
  • Since My Rectangle is a composition, I cannot access the behavior in MColor or MBorder exclusively.\nMixins have to be applied one at a time.\n
  • \n
  • Since My Rectangle is a composition, I cannot access the behavior in MColor or MBorder exclusively.\nMixins have to be applied one at a time.\n
  • Originally in self\nthen developed by nathanel scharli in smalltalk.\nWith operations\n\n
  • Self traits do not provide composition operators.\n
  • Originally in self\nthen developed by nathanel scharli in smalltalk.\nWith operations\n\n
  • Originally in self\nthen developed by nathanel scharli in smalltalk.\nWith operations\n\n
  • Object evolution\n
  • Streams are used to iterate over sequences of elements such as sequenced collections, files, and network streams. Streams offer a better way than collections to incrementally read and write a sequence of elements.\n\n
  • \n
  • \n
  • The potential combination of all these various types of streams leads to an explosion in the number of classes.\n\n
  • Pharo stream hierarchy\n
  • \n
  • Traditional stream implementations check in every method if the underlying stream is still opened. With talents we can avoid such cumbersome checks and dynamically acquire a ClosedStreamTalent when a stream is closed.\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Structural changes\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • We instruments the interesting objects\n
  • We instruments the interesting objects with meta-objects which state under which circumstances the events have to be triggered\n\n
  • We instruments the interesting objects with meta-objects which state under which circumstances the events have to be triggered\n\n
  • We instruments the interesting objects with meta-objects which state under which circumstances the events have to be triggered\n\n
  • \n
  • The next snippet of code describes their motivating example of a shopping cart discount. Every time a low demanded product is purchased a discount is applied to the purchase value.\n\n
  • \n
  • \n
  • \n
  • JPI\n
  • JPI\n
  • We instruments the interesting objects with meta-objects which state under which circumstances the events have to be triggered\n\n
  • dynamic JPI\n
  • The key characteristics are that we have a dynamically defined interface\nJPI have to define and modify the source code previous to execution\nWe can adapt dynamically, no anticipation.\nThe explicit meta-objects allow us to explicitly and dynamically query objects to know which events they can trigger.\n
  • \n
  • now have new possibilities that we can rethink existing tools.\n
  • Does OCR have a meaningful impact on the applications I use every day? Does it change anything?\n
  • \n
  • \n
  • \n
  • We have to go back to the code\n
  • \n
  • We have to go back to the code\n
  • We have to go back to the code\n
  • \n
  • Questions 15, 19, 20, 28 and 33 all have to do with tracking state at runtime. Consider in particular question 15: Where is this variable or data structure being accessed? Let us assume that we want to know where an instance variable of an object is being modified. This is known as keeping track of side-effects [3]. One approach is to use step-wise operations until we reach the modification. However, this can be time-consuming and unreliable. Another approach is to place breakpoints in all assignments related to the instance variable in question. Finding all these assignments might be troublesome depending on the size of the use case, as witnessed by our own experience.\nTracking down the source of this side effect is highly challenging: 31 of the 38 methods defined on InstructionStream access the variable, comprising 12 assignments; the instance variable is written 9 times in InstructionStream’s subclasses. In addition, the variable pc has an accessor that is referenced by 5 intensively-used classes.\n\n
  • Question 22 poses further difficulties for the debugging approach: How are these types or objects related? In statically typed languages this question can be partially answered by finding all the references to a particular type in another type. Due to polymorphism, however, this may still yield many false positives. (An instance variable of type Object could be potentially bound to instances of any type we are interested in.) Only by examining the runtime behavior can we learn precisely which types are instantiated and bound to which variables. The debugging approach would, however, require heavy use of conditional breakpoints (to filter out types that are not of interest), and might again entail the setting of breakpoints in a large number of call sites.\n\n
  • Back-in-time debugging [4], [5] can potentially be used to answer many of these questions, since it works by maintain- ing a complete execution history of a program run. There are two critical drawbacks, however, which limit the practical application of back-in-time debugging. First, the approach is inherently post mortem. One cannot debug a running system, but only the history of completed run. Interaction is therefore strictly limited, and extensive exploration may require many runs to be performed. Second, the approach entails considerable overhead both in terms of runtime performance and in terms of memory requirements to build and explore the history.\n\n
  • \n
  • We add one or more meta-objects to one or more objects depending on the case, all this happens in the back end.\n
  • \n
  • \n
  • double dispatch\n
  • one of the nodes was not correctly rendered\n
  • We have more commands that the ones in the debugger, but we did not know how to put them there.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • halt on next specific messages\n
  • Render the traditional UI obsolete. \n30+ years of debugging in the same way.\n
  • \n
  • \n
  • \n
  • What is the relationship between this and the domain? picture again\n
  • new dimension of problem-domain\n
  • new dimension of problem-domain\n
  • TOOLS 2011\n
  • \n
  • \n\n
  • \n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Clicking and drag-and-dropping nodes refreshes the visualization, thus increasing the progress bar of the corresponding nodes. This profile helps identifying unnecessary rendering. We identified a situation in which nodes were refreshing without receiving user actions.\n
  • TOOLS 2011\n
  • In the remainder of this presentation I am going to show how to address these issues.\nThe graphic displays the architecture of the Bifröst System.\nIt also serves as an agenda for the remainder of this presentation.\n
  • Logo?\n
  • \n
  • Traces are not directly related to the runtime entities\n
  • Traces are not directly related to the runtime entities\n
  • Traces are not directly related to the runtime entities\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • We do not know what to evolve or who should evolve.\nWe need some spreading of the evolution like a disease or cure.\n\nThe adaptation cannot be seen by other objects which are in a different execution.\nThe adaptation is dynamically set.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • The big difference is that we reify the execution, the dynamic context so we can reflect on them and decide when they should finish, undeploy, etc\n
  • \n
  • \n
  • \n
  • The propagation is not thread local.\n
  • Logo?\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • The propagation is not thread local.\n
  • \n
  • \n
  • The impact to the system is bearable \n
  • We do not annoy any other and we have an impact but is only hitting us since others cannot see it.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Logo?\n
  • \n
  • \n
  • \n
  • \n
  • Using Pier and adapting only Pier we get a 20 % negative impact in average in the different use cases.\n
  • If we adapt the whole smalltalk image.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • technique that supports dynamic dispatch amongst several, possibly independent instrumentations. These instrumentations are saved and indexed by a version identifier. A Prisma scope can be related to a particular version of instrumentations over objects’ methods. When the dynamic extent is running only the meth- ods instrumented versions indexed by the scope should be executed.\n\n
  • What is the problem with AOP?\n- it was not originally motivated by reifications.\n- the debugger in ALIA4J is going into that direction\n- it is more like a language to express certain “events” but not a full model, aspects are not reified.\n- Do not get me wrong, it is amazing what they have achieved, but the reification problem is still a big one, Mainly because it was not born in a dynamic language.\n
  • \n
  • Following the idea of per-object meta-objects Rajan and Sullivan propose per-object aspects. An aspect deployed on a single object only sees the join points produced by this object. This join point observation can be stopped at any time.\n\n
  • CaesarJ provides deploy blocks which restrict behavioral adaptations to take place only within the dynamic extent of the block. The scope is explicitly embedded within the application code, but the this approach has an implicit exit point which is the ending of the execution of the deploy block. No value can be parameterized in the deploy block. The adaptation is bound at run time but the adaptation cannot be unbound nor rebound during the execution. Finally, the adaptation is applied locally to the thread executing the deploy block.\n\n
  • AspectScheme is an aspect-oriented procedural language where pointcuts and advices are first-class values. AspectScheme introduces two deployment expressions. One expression can dynamically deploy an aspect over a body expression. The other can statically deploy an aspect which only sees join points occurring lexically in its body.\n\n\n
  • AspectS is a dynamic aspect system defined in the context of Smalltalk. AspectS support first-class activation conditions which are objects modeling a dynamic condition. Since this a Smalltalk implementation the condition can be dynamically bound at runtime. This means that condition can be installed and uninstalled at runtime. Generally, this changes are global but as Hirschfeld and Costanza showed thread locality can be achieved.\n\n
  • ALIA4J is an approach for implementing language extensions by reifying dispatching. It uses a fine-grained intermediate representation close to the source level abstractions. The key objective of ALIA4J is to allow researchers to focus on developing source languages for solving specific problems. For example, ALIA4J implemented CaesarJ thus it supports object-specific adaptations. One shortcoming of this approach is that even though the dispatching is reified the adaptation abstraction (meta-object) is not. Thus, achieving dynamically defined interfaces is not possible and so the source code has to be modified to signal an event interface change.\n\n\n
  • ALIA4J AOP specific debugger realizes the need to explicitly model some AOP abstractions. The authors reflect that aspects adaptation are lost when weaved and is this implicitness that hinders the correct detection and solution of aspect-related bugs. Yin et al. define a debugging model which is aware of aspect-oriented concepts. This solution is targeted at AOP events. We require a solution targeted at object behavioral events.\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Cells have more power. And OOP stems from cells. What if we combine managed with unmanaged memory management?\n\nhttp://www.wormbook.org/chapters/www_programcelldeath/programcelldeath.html\n
  • Garbage collection is cool, but a black box for most people. Not controllable. Object are not involved.\n
  • In todays programming language you can choose between two. It is very black and white.\n- Either you have “automatic” collection, or you do everything “manually”.\n- In an automatic setup everything is “temporary”, in a manual all your actions are “permanent”.\n- Either you have a “referenced” object, or an “unreferenced” object. You have no control over unreferenced objects, and it is hard to get them back.\n- Either you have a “strong” reference, or “weak” one. You have to know upfront and you cannot easily change your mind on the fly.\n
  • Implementing good caches is difficult. Either they are too aggressive and keep objects around for too long1 or they are too relaxed and let objects die too soon. If the objects can decide themselves how long they should stick around it is much simpler to implement a good cache.\n\n
  • They disappear to fast if they are not referenced, like this\nthey could decide to stick around.What makes them faster if they are required again. Same\nin java. With the string sharing thing.A string that has no references disappears immediately\nand is not shared anymore, should it appear again.\n\n
  • \n
  • \n
  • Tanter in scoping strategies mention the problem of stating a condition for undeployment\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

Object-Centric Reflection - Thesis Defense Object-Centric Reflection - Thesis Defense Presentation Transcript

  • Object-Centric ReflectionUnifying Reflection and Bringing it Back to Objects PhD Defense Jorge Ressia Advisor Oscar Nierstrasz
  • Reflection
  • A reflective computational system iscapable of inspecting, manipulating andaltering its representation of itself. Smith, 1982
  • Meta-levelBase-level
  • StructuralReflectionBehavioralReflection
  • Reflection Today
  • ReflectionRequirements
  • Mesage Object
  • Message sendMessage Object
  • Partial Reflection
  • SelectiveReifications
  • Unanticipated Changes
  • Runtime Integration
  • Meta-levelComposition
  • Scoped Reflection
  • Object-specific Reflection
  • Profiling
  • Profiling:Is the activity of analyzing a programexecution.
  • 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 reconfigured
  • 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/
  • Mondrian
  • C omp lexity stemand Ducasse 2003Sy zaLan
  • little impact on the overall execution. This sampling technique is uall mainstream profilers, such as JProfiler, YourKit, xprof [10], an MessageTally, the standard sampling-based profiler in Pharo Smtually describes the execution in terms of CPU consumption and ieach 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% othe method displayOn: defined in the class MORoot. A root is thenested node that contains all the nodes of the edges of the visuageneral profiling information says that rendering nodes and edge
  • CPU time profilingMondrian [9] is an open and agile visualization engine. Mondrian describes a Which is the relationship?visualization 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 of
  • Debugging
  • Debugging:Is the process of interacting with arunning software system to test andunderstand its current behavior.
  • Mondrian
  • C omp lexity stemand Ducasse 2003Sy zaLan
  • Rendering
  • Shape and Nodes
  • How do we debug this?
  • Breakpoints
  • ConditionalBreakpoints
  • { { { { } } } } { }
  • { { { { } } } } { }
  • Developer Questions
  • 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 pointin the code? (Q.28) What parts of this data structure are accessed in thiscode? (Q.33)
  • 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 pointin the code? (Q.28) What parts of this data structure are accessed in thiscode? (Q.33) llito Si etal. g softwar e ask durin gr ammers s. 2008 Questi ons pro ution task evol
  • 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)
  • What is theproblem?
  • TraditionalReflection
  • visualization 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 methods Profilingunder 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
  • DebuggingWhen 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)
  • Object Paradox
  • ObjectParadox
  • ObjectParadox
  • ObjectParadox Reflection Requirements
  • ObjectParadox Reflection Requirements
  • Object Paradox Unified Reflection Uniform RequirementsApproach
  • Object Paradox Unified Reflection Uniform RequirementsApproach
  • Thesis:To overcome the object paradox while providing aunified and uniform solution to the key reflectionrequirements we need an object-centric reflectivesystem which targets specific objects as the centralreflection mechanism through explicit meta-objects.
  • Thesis:To overcome the object paradox while providing aunified and uniform solution to the key reflectionrequirements we need an object-centric reflectivesystem which targets specific objects as the centralreflection mechanism through explicit meta-objects.
  • Thesis:To overcome the object paradox while providing aunified and uniform solution to the key reflectionrequirements we need an object-centric reflectivesystem which targets specific objects as the centralreflection mechanism through explicit meta-objects.
  • Thesis:To overcome the object paradox while providing aunified and uniform solution to the key reflectionrequirements we need an object-centric reflectivesystem which targets specific objects as the centralreflection mechanism through explicit meta-objects.
  • Thesis:To overcome the object paradox while providing aunified and uniform solution to the key reflectionrequirements we need an object-centric reflectivesystem which targets specific objects as the centralreflection mechanism through explicit meta-objects.
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 56
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 57
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 58
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 59
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 60
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 61
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 62
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 63
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 64
  • Object-Centric Reflection
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 66
  • 2010 time. Nierstrasz @run delsnggli,T. Gîrba and OMo e R J. R essia, L.
  • Organize the Meta-level
  • ExplicitMeta-objects
  • Object-Centric
  • UniformSolution
  • Class Meta-object Object
  • Class Meta-object Object
  • Class Meta-objectAdapted Object
  • Runtime
  • AST adaptation
  • Source Code Syntactic Analysis Semantic Analysis AST Code Manipulation Generation Executable Code
  • Class Meta-objectAdapted Object
  • StructuralReflection
  • BehavioralReflection
  • Composition
  • Meta-object Meta-object
  • Meta-object Meta-objectComposedMeta-object
  • Any adaptation goesthrough a meta-object
  • No implicitInteractions
  • ReflectionRequirements
  • Partial Reflection
  • SelectiveReifications
  • Unanticipated Changes
  • Runtime Integration
  • Meta-levelComposition
  • Scoped Reflection
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language
  • Development 94
  • Reuse
  • Mixins
  • Linear Composition
  • Single Composition
  • Traits
  • Class = Superclass + State + Traits + Glue methods
  • MultipleComposition
  • Flatten Composition
  • Problem
  • Streams
  • readwriteboth
  • binarycharacter-based
  • memory socketdatabase file
  • Stream PositionableStream NullStream ReadStream WriteStream ReadWriteStream TextStream LimitedWriteStreamRWBinaryOrTextStream
  • Explosion of classes
  • DynamicComposition
  • Talents S PE 2 012 , 011Nierstrasz, F. Perin and ST 2 . IW ssia,T. Gîrba, O i J. Re L . Renggl
  • Dynamicallycomposable units of reuse
  • Meta-object
  • Special Composition
  • Operations
  • Define a method
  • readStreamTalent defineMethodNamed: #isReadStream performing: ^ true.
  • Exclude a method
  • readStreamTalent excludeMethodNamed: #isReadStream
  • Replace a method
  • readStreamTalent replaceMethodNamed: #isReadStream performing: ^ true.
  • Read and Buffered Stream
  • Composition Operators
  • Composition
  • aStream := Stream new.aStream acquire: ( readStreamTalent , bufferedStreamTalent ).
  • Alias
  • aStream := Stream new.aStream acquire: readStreamTalent ,( bufferedStreamTalent @ {#isReadStream -> #isReadBufferedStream})
  • Exclusion
  • aStream := Stream new.aStream acquire: readStreamTalent , (bufferedStreamTalent - #isReadStream).
  • Talents
  • Talents S PE 2 012 , 011Nierstrasz, F. Perin and ST 2 . IW ssia,T. Gîrba, O i J. Re L . Renggl
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 134
  • BehavioralReflection
  • OperationalDecomposition
  • Running System = Sequence of Events
  • ObjectObjectObjectObject
  • Object DebuggerObject Feature AnalysisObject ProfilerObject
  • Object DebuggerObject Feature AnalysisObject ProfilerObject
  • Object DebuggerObject Feature AnalysisObject ProfilerObject
  • Chameleon
  • Object DebuggerObject Feature AnalysisObject ProfilerObject
  • Object DebuggerObject Feature AnalysisObject ProfilerObject
  • ObjectObjectObjectObject
  • ObjectObjectObjectObject
  • Meta-object ObjectMeta-object Object Meta-object ObjectMeta-object Object
  • Meta-object ObjectMeta-object Object Meta-object ObjectMeta-object Object
  • Definition of new events
  • Adaptation on top of these events
  • EventInstrumentor reify: PurchaseEvent onClass: Cart selector: #purchase
  • ChameleonAnnouncer subscribe: aDiscountChecker to: PurchaseEvent
  • EventInstrumentor reify: PointsPurchaseEvent onObject: aCart selector: #purchase
  • No source code modification
  • Meta-object ObjectMeta-object Object Meta-object ObjectMeta-object Object
  • Dynamically defined events interface
  • Reification of the adaptation
  • Chameleon
  • Rethink tools
  • Applications
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 157
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 158
  • 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)
  • { { { { } } } } { }
  • { { { { } } } } { }
  • Object-Centric Debugging 2 201Nierstrasz ICSE . rgel and O J. Ressi a, A, Be
  • { { { { } } } } { }
  • { { { { } } } } { }
  • { { { { } } } } { }
  • What does it mean?
  • interceptingaccess to object- specific runtime state
  • monitoringobject-specific interactions
  • supporting live interaction
  • Mondrian
  • Shape and Nodes
  • halt on object in call
  • InstructionStream
  • pc
  • How do we debug this?
  • Debugging through operations 18 step in for first modification30 operations for next modification
  • Setting breakpoints 31 method accessing the variable 9 assignmentspc setter is used by 5 intensively used classes
  • stack-centric debugging InstructionStream class>>on: InstructionStream class>>new InstructionStream>>initialize step into, CompiledMethod>>initialPC step over, InstructionStream>>method:pc: resume InstructionStream>>nextInstruction MessageCatcher class>>new InstructionStream>>interpretNextInstructionFor: ... object-centric debugging centered on centered onthe InstructionStream class the InstructionStream object initialize on:next message, next message, method:pc: new next change nextInstruction ... next change interpretNextInstructionFor: ...
  • 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 frompackage
  • Object-Centric Debugging 2 201Nierstrasz ICSE . rgel and O J. Ressi a, A, Be
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 183
  • 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/
  • Domain-Specific Profiling 3CPU time profiling Which is the relationship?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.CoveragePetitParser is a parsing framework combining ideas from scannerless parsing,
  • ObjectsSource Traditional Code Profilers
  • ObjectObjects ProfilersSource Traditional Code Profilers
  • MetaSpy JOT 2 012 al. Ressia et
  • Instrumenter Profiler
  • Domain Profilers Domain Object Domain Object Domain Object
  • Domain Profilers Domain Object Domain Object Domain ObjectInstrumentation
  • Domain Profilers Domain Object Domain Object Domain ObjectInstrumentation
  • Specify the Domain interestsCapture the runtime informationPresent the results
  • Mondrian Profiler
  • MondrianProfiler>>setUpself model root allNodes do: [ :node | self observeObject: node selector: #displayOn: do: [ ... counting ... ] ]
  • MetaSpy JOT 2 012 al. Ressia et
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 197
  • LiveFeature Analysis
  • LiveFeature Analysis 2010 dels l. Mo Denker eta
  • Software Feature:A distinguishing characteristic of asoftware item. IE EE 829
  • Traces{ { { { { { } { { } } } } } } } } } { {
  • Traces{ { { { { { } { { } } } } } } } } } { {
  • Traces{ { { { { { } { { } } } } } } } } } { {
  • { { { { } } } } } { { }
  • Paint AST nodes
  • What if we do notknow what to evolve?
  • ?
  • ExecutionReification
  • Reification of Context
  • Reuse
  • Propagation
  • Dynamically install and uninstall
  • Thread Locality
  • LiveFeature Analysis
  • loginExecution := Execution new.loginExecution when: ASTNodeExecutionEvent do: [ :node | node addFeatureAnnotation: #login ]
  • loginExecution executeOn: [ WebServer new loginAs: admin password: pass ]
  • printingExecution := Execution new.printingExecution when: ASTNodeExecutionEvent do: [ :node | node addFeatureAnnotation: #printing ]
  • printingExecution executeOn: [ WebServer new printStatusReport ]
  • ScopedReflection
  • Back in time Debugger
  • Back in time Debugger Debu gger w Floal. ECOOP 2008 O b ject nhard e t Lie
  • name value init@t1 null predecessor name value :Person field-write@t2 Doe predecessor name value field-write@t3 Smithperson := Person new t1...name := Doe t2...name := Smith t3
  • Adapt reached objects
  • Controlled Impact
  • Thesis:To overcome the object paradox while providing aunified and uniform solution to the key reflectionrequirements we need an object-centric reflectivesystem which targets specific objects as the centralreflection mechanism through explicit meta-objects.
  • Object Paradox Unified Reflection Uniform RequirementsApproach
  • Object-CentricApplications MetaSpy Debugging Talents ChameleonHost Language 237
  • Performance
  • LiveFeature Analysis
  • LiveFeature Analysis 2010 dels l. Mo Denker eta
  • 179classes
  • 1292methods
  • adaptedall AST nodes
  • PRCommand >> context: aContext context := aContext
  • 20%slower
  • 35 times slower
  • Implementation
  • AST adaptation
  • Source Code Syntactic Analysis Semantic Analysis AST Code Manipulation Generation Executable Code
  • methodDictClass MethodDictionary CompiledMethod 1 * ReflectiveMethod
  • Object Key run: #isPoint with: #() in: aPoint instance-of message send 3 aMethodDictionary lookup isPoint : aMetaObjectReflectiveMethod Point isZero : aCompiledMethod isPoint run: #isPoint with: #() in: aPoint 2 4 aPoint aMetaObject aScopedMethodDictionary isPoint : aReflectiveMethod 1 5 run: #isPoint with: #() in: aPointaPoint isPoint
  • Object Discovery
  • Feasibility
  • Dynamic Aspects
  • PBI
  • PBI 011 Eric Tanter SD 2 d AO alter Binder an M oret, W P hilippe
  • AOP
  • Dynamic Aspects
  • Per-object Aspects
  • Per-object Aspects ftw. Eng. SOF T So SIG 003 tes 2llivan No jan and Su Ra
  • CaesarJ
  • CaesarJ s AOS D 06 a nsac tionic etal. Tr Arac
  • AspectScheme
  • AspectScheme S CP 2 006amurthi. n an d Krish n, Tucker, Dutchy
  • AspectS
  • AspectS 6 200nza O DAL a and Co st H irschfeld
  • ALIA4J
  • ALIA4J O LS 2 011kşit TO Sewe, Mezini, and A h, Bockisc
  • ALIA4J AOP Debugger
  • ALIA4J AOP Debugger 2 201şit AOSD h, and A k Yin, Bockisc
  • Related Work
  • Deployment Strategies
  • Deployment Strategies SD 2 008 AO Eric Tanter
  • ScopingStrategies
  • ScopingStrategies DLS 2009 er Eric Tant
  • dynamic extentpropagation functionactivation conditionadaptations
  • Future Work
  • Rethink thedebugger UI
  • Suicide Objects
  • Barbara Conradt, Programmed cell death
  • o bel 2 002ohn E. Sulston N ne r and J ydne y Bren ob Ho rvitz, SB Barbara Conradt, Programmed cell death
  • Automatic ManualTemporary PermanentReferenced Unreferenced Strong Weak
  • Cache
  • Strings
  • Dynamic Scoping
  • Undeployment Conditions
  • Let objects decide
  • More Reflective Applications
  • Talents
  • Scoped Talents
  • Dangerous?
  • I believe the argument that reflection is dangerous because it givesprogrammers too much power is a specious one. Existing programminglanguages already give clumsy programmers more than ampleopportunities to shoot themselves in the foot. Ill concede that reflectivesystems allow the clumsy programmer to fire several rounds per secondinto his foot, without reloading. Still, Im confident that, as is the casewith features such as pointers, competent programmers will makeappropriate use of the power of reflection with care and skill. Potentialabuse by inept programmers should not justify depriving theprogramming community of a potentially vital set of tools. Brian Foote