Object-Centric
      Reflection
Unifying Reflection and Bringing it Back to
                 Objects

              PhD Defense
             Jorge Ressia
                Advisor
             Oscar Nierstrasz
Reflection
A reflective computational system is
capable of inspecting, manipulating and
altering its representation of itself.

                          Smith, 1982
Meta-level


Base-level
Structural
Reflection

Behavioral
Reflection
Reflection
 Today
Reflection
Requirements
Mesage


         Object
Message send
Message


          Object
Partial Reflection
Selective
Reifications
Unanticipated
  Changes
Runtime Integration
Meta-level
Composition
Scoped Reflection
Object-specific
  Reflection
Profiling
Profiling:
Is the activity of analyzing a program
execution.
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 2003
Sy zaLan
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
CPU time profiling
Mondrian [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 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
Debugging
Debugging:
Is the process of interacting with a
running software system to test and
understand its current behavior.
Mondrian
C omp lexity
  stemand Ducasse 2003
Sy zaLan
Rendering
Shape and Nodes
How do we debug
     this?
Breakpoints
Conditional
Breakpoints
{               {
    {                   {
                            }
        }
        }
            }       {       }
{               {
    {                   {
                            }
        }
        }
            }       {       }
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 point
in the code? (Q.28)
  What parts of this data structure are accessed in this
code? (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 point
in the code? (Q.28)
  What parts of this data structure are accessed in this
code? (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 the
problem?
Traditional
Reflection
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


                                                 Profiling
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
Debugging


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 Paradox
Object
Paradox
Object
Paradox
Object
Paradox



           Reflection
          Requirements
Object
Paradox



           Reflection
          Requirements
Object
           Paradox



 Unified               Reflection
 Uniform             Requirements
Approach
Object
           Paradox



 Unified               Reflection
 Uniform             Requirements
Approach
Thesis:

To overcome the object paradox while providing a
unified and uniform solution to the key reflection
requirements we need an object-centric reflective
system which targets specific objects as the central
reflection mechanism through explicit meta-objects.
Thesis:

To overcome the object paradox while providing a
unified and uniform solution to the key reflection
requirements we need an object-centric reflective
system which targets specific objects as the central
reflection mechanism through explicit meta-objects.
Thesis:

To overcome the object paradox while providing a
unified and uniform solution to the key reflection
requirements we need an object-centric reflective
system which targets specific objects as the central
reflection mechanism through explicit meta-objects.
Thesis:

To overcome the object paradox while providing a
unified and uniform solution to the key reflection
requirements we need an object-centric reflective
system which targets specific objects as the central
reflection mechanism through explicit meta-objects.
Thesis:

To overcome the object paradox while providing a
unified and uniform solution to the key reflection
requirements we need an object-centric reflective
system which targets specific objects as the central
reflection mechanism through explicit meta-objects.
Object-Centric
Applications                     MetaSpy
                Debugging


                      Talents    Chameleon




Host Language




                        56
Object-Centric
Applications                     MetaSpy
                Debugging


                      Talents    Chameleon




Host Language




                        57
Object-Centric
Applications                     MetaSpy
                Debugging


                      Talents    Chameleon




Host Language




                        58
Object-Centric
Applications                     MetaSpy
                Debugging


                      Talents    Chameleon




Host Language




                        59
Object-Centric
Applications                     MetaSpy
                Debugging


                      Talents    Chameleon




Host Language




                        60
Object-Centric
Applications                     MetaSpy
                Debugging


                      Talents    Chameleon




Host Language




                        61
Object-Centric
Applications                     MetaSpy
                Debugging


                      Talents    Chameleon




Host Language




                        62
Object-Centric
Applications                     MetaSpy
                Debugging


                      Talents    Chameleon




Host Language




                        63
Object-Centric
Applications                     MetaSpy
                Debugging


                      Talents    Chameleon




Host Language




                        64
Object-Centric
 Reflection
Object-Centric
Applications                     MetaSpy
                Debugging


                      Talents    Chameleon




Host Language




                        66
2010
                         time. Nierstrasz
                    @run
   delsnggli,T. Gîrba and O
Mo    e         R
 J. R essia, L.
Organize the
 Meta-level
Explicit
Meta-objects
Object-Centric
Uniform
Solution
Class

          Meta-object




 Object
Class

          Meta-object




 Object
Class

            Meta-object




Adapted Object
Runtime
AST adaptation
Source
 Code
         Syntactic
         Analysis

                     Semantic
                     Analysis

      AST                         Code
   Manipulation                 Generation


                                Executable
                                  Code
Class

            Meta-object




Adapted Object
Structural
Reflection
Behavioral
Reflection
Composition
Meta-object
              Meta-object
Meta-object
              Meta-object




Composed
Meta-object
Any adaptation goes
through a meta-object
No implicit
Interactions
Reflection
Requirements
Partial Reflection
Selective
Reifications
Unanticipated
  Changes
Runtime Integration