Extending Rotor with Structural Reflection to support Reflective Languages

  • 307 views
Uploaded on

Presentation of the results of the project "Extending Rotor with Structural Reflection to support Reflective Languages" at Microsoft Research, Redmond, Washington (USA)

Presentation of the results of the project "Extending Rotor with Structural Reflection to support Reflective Languages" at Microsoft Research, Redmond, Washington (USA)

More in: Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
307
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Extending Rotor with Structural Reflection to support Reflective Languages
  • 2. Adaptiveness and Adaptability
    • The dynamic manipulation (evolution) of system behavior and structure is becoming increasingly important to develop adaptive and adaptable applications
      • A system is adaptive if it is able to change its behavior ( by itself ) according to the changes in its environment, or within itself
      • A system is adaptable if the user could dynamically produce a new system behavior
    • There are different approaches to construct adaptable(ive) software
      • Adaptive (Dynamic) Languages
        • Python, Dylan, Ruby, Smalltalk, Self or CLOS)
      • Adaptive Paradigms
      • Agile and Adaptive Methodologies
      • A lot of Domain Specific Adaptive Frameworks
    Introduction
  • 3. Dynamic Languages
    • Programming languages that support reasoning about / customizing their own structure , behavior and environment , supporting self-modifying features and dynamic code generation
    • As a side effect of this dynamism, dynamic programming languages are dynamically typed
    • For example, it is possible to dynamically
      • Change the interface of objects and classes
      • Modify the implementation of specific methods
      • Adapt the structure of objects
      • Generate new code
      • Modify an object’s type
      • Customize the behavior of a set of classes ( meta-classes )
    Introduction
  • 4. Pros and Cons
      • Facilitate the development of adaptive and adaptable software
      • Design -time and runtime integration
      • Making new software entities first-class objects (modules, classes, meta-classes, objects, methods, fields and types) increases behavior parameterization (factorization)
    • Due to these benefits, static languages (Java or C#) are incorporating more and more dynamic features
    • However, static type-checking has important benefits
      • The lack of static type-checking may cause a loss of safety
        • Test-driven development (PyUnit, JUnit or NUnit) could be used in some scenarios
        • Mixing static and dynamic type-checking could be interesting, when developing adaptable software
      • Performance caused by inferring types (and checking) at runtime
    Introduction
  • 5.
    • Our Project, Extending Rotor with Structural Reflection to support Reflective Languages
    • has tried to response these questions
      • Is it possible to improve runtime performance of reflective languages?
      • Is it possible to make static and dynamic languages interoperate?
      • Is it possible to combine the best of both worlds ( static typing where possible, dynamic typing when needed )?
    • The main objective is to enhance Rotor with structural reflective primitives offered by dynamic languages, in order to evaluate
      • feasibility of making the CLI a runtime reflective platform (combining static and dynamic languages)
      • performance cost (vs. static rotor) and performance benefits (vs. interpreted counterparts)
    Я Rotor Introduction
  • 6. Contents
    • Introduction
    • Reflection
    • Structural Reflection in Rotor
    • Implementation
    • Assessment
    • Conclusions
  • 7. Reflection
    • Reflection is the capability of a computational system to reason about/act upon itself, adjusting itself to changing conditions
      • Its computational domain is enhanced by its own representation , offering its semantics and structure as if they were computable data
    • Runtime reflection offers dynamic adaptation of running systems ( dynamic languages )
    • Regarding to what can be reflected, reflection can be classified into
      • Introspection : program structure may be consulted, but not modified (e.g. Java and C# reflective capabilities)
      • Structural Reflection: program structure can be modified and those changes should be reflected (e.g. modifying attributes and methods of Python classes)
      • Computational Reflection: modifying program behavior (e.g. extending the message passing mechanism to develop a trace log with a MOP)
    Reflection
  • 8. Extending Rotor’s Reflection
    • Runtime adaptiveness has been an important issue in .Net’s design
      • Introspection services of the System.Reflection namespace
      • Generative programming with the Reflection.Emit namespace
      • Dynamic inspection of the declarative information offered by attributes
    • Structural Reflection is a step forward to adaptiveness, permitting the modification of program’s structure at runtime
    • There are languages that offer this level of reflection: Python, Ruby, Dylan, Smalltalk or CLOS
    • Extending Rotor with structural reflection has
      • Made the CLI a platform to directly support reflective features of dynamic languages
      • Made the most of its introspective , attribute and generative programming features
      • Improved runtime performance of existing implementations, using its JIT compiler
      • Offered direct interoperability between X.Net and dynamic languages
    Reflection
  • 9. Contents
    • Introduction
    • Reflection
    • Structural Reflection in Rotor
    • Implementation
    • Assessment
    • Conclusions
  • 10. Structural Reflective Facilities
    • We have extended Rotor with the following summary of structural reflective capabilities
      • Fields Manipulation . Dynamic addition, deletion and updating of
        • The structure of classes (static and non-static fields)
        • The structure of a single object
      • Methods manipulation . Dynamic addition, deletion and updating of
        • Methods of classes (static and instance methods)
        • Methods of a specific object
      • The implementation of new methods can be
        • obtained as copies of existing ones
        • dynamically generated by means of the System.Reflection.Emit namespace
    • The programmer may combine these facilities with .Net introspective features to create adaptive(able) software in an easier way
    Structural Reflection in Rotor
  • 11. Python Example class Point : "Constructor" def __init__ (self, x, y): self.x=x self.y=y "Move Method" def move (self, relx, rely): self.x=self.x+relx self.y=self.y+rely "Draw Method" def draw (self): print "(" +str(self.x)+ "," +str(self.y)+ ")" point=Point(1,2) point.draw() # (1,2) # Modify attributes of # a single object point.z=3 print point.z # 3 # Modify methods of # a single object def draw3D (self): print "(" +str(self.x)+ "," +str(self.y)+ "," +str(self.z)+ ")" point.draw3D=draw3D point.draw3D() # (1,2,3) # Modify methods of a class def getX (self): return self.x Point.getX=getX print point.getX() # 1 Structural Reflection in Rotor
  • 12. Conceptual Problems
    • There are conceptual issues to tackle when adding structural reflective capabilities to class-based object-oriented systems
      • Modifying classes structure  Schema evolution
        • Default values to new fields
        • Runtime exceptions to manage obsolete code
      • Modifying the structure of a single object  Schema versioning (new class for that object)
        • Class identity (different classes, same type)
        • Memory consumption
        • Class structure consistency (future modifications of “first” class should imply modifications of “second” class)
      • … Imply a complex implementation of an incoherent computational model (e.g. MetaXa)
    Structural Reflection in Rotor
  • 13. Prototype-Based OO Comp. Model
    • The prototype-based object-oriented computational model (e.g. Self or Mootstrap)
      • Does not use classes ( only objects )
    Point x,y:Integer draw() move(x,y:Integer) p:Point x=245 y=-23 Class-based model Prototype-based model inheritance Prototype Cloning Point pointPrototype p Trait object Prototype object Structural Reflection in Rotor
      • Shared behavior could be defined in objects called trait objects
      • Common structure is defined with prototype objects
      • Object’s instantiation is performed by cloning prototypes
    Method implementation move Method implementation draw 0 y 0 x -23 y 245 x
  • 14. Overcoming to Schema Evolution
    • Prototype-based OO model overcomes the schema versioning problem detected with classes
    • It is possible to modify the structure of a single object in a coherent way
    draw method implementation move method implementation x 12 y 0 x 0 y 0 x 1 y 2 p1 p2 Point pointPrototype Structural Reflection in Rotor z 3
    • Modify attributes of a single object
    distance method
    • Modify methods of a single object
    rotate method implementation
    • Modify behavior and structure of a class
  • 15. Structural Reflection in Rotor
    • But, Rotor uses a class-based object-oriented computational model !!!
    • It is necessary to maintain classes because of
      • Existing (class-based) legacy code
      • Languages and applications interoperability
    • The programmer will continue using classes , but when using new structural reflective capabilities
      • Classes will be treated as trait objects (shared behavior and lazy schema evolution for fields)
      • Objects will be capable of grouping both attributes and methods (slots)  No schema versioning
    • Internally we use a prototype-based reflective model (module object of rotor)
    Structural Reflection in Rotor
  • 16. Architecture
    • Supporting both class-based
    • and prototype-based OO models
    • Manipulation of methods :
      • Classes : Shared behavior (both models)
      • Objects : Specific behavior (mainly prototype-based model)
    • Manipulation of fields :
      • Classes : Lazy schema evolution ( class-based model)
      • Objects : Specific instance modification (mainly prototype-based model)
    • “ Static typing where possible, dynamic typing when needed ”
    Structural Reflection in Rotor Compilation MSIL Я Rotor Operating System Execution Interaction Interaction C# Python Reflective C# Statically typed language (legacy code) Statically and Dynamically typed language Dynamically typed language
  • 17. Contents
    • Introduction
    • Reflection
    • Structural Reflection in Rotor
    • Implementation
    • Assessment
    • Conclusions
  • 18. BCL Interface
    • The final implementation consists of
      • A set of new BCL reflective primitives
      • The extension of appropriate IL instruction semantics (code generated by the JITter)
    • The BCL has been extended with a System.Reflection.Structural namespace
    • A summary of the most significant primitives (static methods of the Structural utility class)
      • [ add , get , remove , alter , exist ] Field : Modify (inspect) the field structure of classes and single objects
      • [ add , get , remove , alter , exist ] Method : work with both classes ( Sytem.Type ) and objects using method descriptions ( MethodInfo )
        • Methods could be cloned from existing ones or dynamically generated with System.Reflection.Emit
      • invoke : executes a class or object method taking into account the prototype-based semantics (and inheritance)
      • [ get , set ] Value : statically-typed field access
    Implementation
  • 19. Sample Code Fragment (BCL)
    • A fragment of C# program that only uses the BCL interface of Я Rotor:
    Implementation RuntimeStructuralFieldInfo rsfi= new RuntimeStructuralFieldInfo( "z", typeof ( int ),3, FieldAttributes.Public); Structural.addField(point,rsfi); // field addition (object) // * Draw3D is the MethodInfo of a new method generated by // means of the System.Reflection.Emit namespace Structural.addMethod(point,draw3D); // method addition (object) Object[] pars={}; // method invocation (object method) Structural.invoke(point,draw3D.ReturnType, "draw3D",pars); // * getX is another MethodInfo Structural.addMethod( typeof (Point),getX); // add class method Console.WriteLine(Structural.invoke( point, getX.ReturnType, "getX", pars ); rsfi = new RuntimeStructuralFieldInfo( "isShowing", typeof ( bool ), false , FieldAttributes.Public); Structural.addField( typeof (Point), rsfi); // add class field
  • 20. Extension of IL Semantics
    • The new reflective model must be supported by the IL instructions , offering the benefits:
      • Making existing (legacy) .Net applications reflective
      • Programmers should make no distinction between static and dynamic (reflective) code
      • Applications needn’t to be recompiled to be adapted
    • We generate new native code, modifying the JIT compiler
    • This IL statements support dynamic type-checking
      • ldfld , ldsfld , ldflda : Load into the stack the field value (or address) following the prototype-based model
      • stfld , stsfld : Store a value into a field, deciding its memory location at runtime
      • call , callvirt : Execute methods following the prototype-based model
    Implementation
  • 21. Implementation Details
    • Inside of Rotor, both classes and objects are instances of the Object class ( object.h )
    • These instances have fixed-size data
      • we couldn’t make objects variable size
    • We placed reflective information of each object inside their SyncBlock ( syncblk.h )
      • Two hash tables were added to dynamically collect reflective members (methods and fields)
    • Reflective primitives manipulate this reflective information
      • New semantics of IL instructions was added modifying the JITter functions ( fjit.cpp ):
        • compileCEE_ { LDFLD , LDFLDA , STFLD , CALL , CALLVIRT }
      • The reflective information is manipulated at runtime by the runtime helper functions ( fjitdef.h ):
      • JIT_ {{ Set , Get } Field { 32 , 64 , Obj }, GetFieldAddr , GetStaticFieldAddr , Test { Method , VirtualMethod }}
      • The rest of the functionality was placed in the BCL
    Implementation
  • 22. Contents
    • Introduction
    • Reflection
    • Structural Reflection in Rotor
    • Implementation
    • Assessment
    • Conclusions
  • 23. Reflective Primitives Assessment
    • Three performance assessments
      • Reflective primitives
      • The cost of adaptiveness (no reflection)
      • Benefits of JIT compilation (vs. existing implementations)
    • We have evaluated the performance of the following reflective primitives
      • [ add , delete ][ method , attribute ]
      • invoke , accessField
      • compared with
      • CPython 2.4. The most widely used interpreted implementation –developed in C
      • ActivePython 2.4 from ActiveState (C)
      • Jython 2.1. Compiles into 100% pure JVM code
      • IronPython 0.6. Generates CLR IL code
    • Reflective primitives have been measured using different scenarios (10,000 iterations each)
    Assessment
  • 24. Reflective Primitives Assessment
      • Я Rotor uses 23.18% average time ( 5.74 times faster) to execute reflective primitives in comparison with CPython
      • Notice that we do not support the whole Python programming language computational model
    Assessment 0 200 400 600 800 1000 1200 1 3 5 7 9 11 13 15 17 19 ActivePython CPython Я Rotor 0 20000 40000 IronPython 1,2 Object attribute addition 3,4 Class attribute addition 5,6 Object attribute deletion 7,8 Class attribute deletion 9,10 Object attribute access 11,12 Class attribute access 13 Object method addition 14 Class method addition 15,16 Object method invocation 17 Class method invocation 18 Object method deletion 19 Class method deletion Jython
  • 25. The cost of Adaptiveness
    • Static ( non-reflective ) operations should also be measured against original Rotor
    • The current cost of flexibility has been measured with the Tommti benchmark that measures:
      • {int,double,long} Arithmetic, trigonometric, input/output, array, exception handling, hash table(s), heap sort, vector, matrix, loops and string operations
    • A performance penalty was only detected in member accesses
    Assessment Rotor Я Rotor 0% 20% 40% 60% 80% 100% int arithmetic double arithmetic long arithmetic trigonometric io array exception hashmap hashmaps heapsort vector matrix loops StringBuilder
  • 26. The cost of Adaptiveness (II)
    • After many optimizations , we have measured ( Я Rotor vs. Rotor)
      • the cost of static ( non-reflective ) primitives
        • Instance field access ( ldfld ): 0.6 times slower
        • Instance method invocation ( call ): 0.6 times slower
      • the execution of real C# application benchmarks
        • LCSCBench (LR parser): 0.81 times slower
        • AHCBench (Compression Algorithm): 2.14 times slower
    Assessment
  • 27. Benefits of JIT Compilation
    • What has been the performance benefit when executing non-reflective code ?
    • We have compared C# Tommti benchmark executed on Я Rotor and CPython
    • Average runtime performance is 9.01 times faster
      • We do not support the whole Python computational model
    • Differences with maps , vectors and files :
      • in .Net, they belong to the BCL (performance overhead)
      • in Python, they are part of the language
    • In both Python and .Net, arrays (matrix) are part of the language
    Assessment 0% 20% 40% 60% 80% 100% int arith. double arith. long arith. trigonometric io array exception hashmap hashmaps heapsort vector matrix loops StringBuilder CPython Features included in the Python PL Я Rotor
  • 28. Contents
    • Introduction
    • Reflection
    • Structural Reflection in Rotor
    • Implementation
    • Assessment
    • Conclusions
  • 29. Major Conclusions
    • JIT compilation is a suitable technique to optimize reflective primitives of dynamic languages
      • 9 times faster when executing non-reflective code
      • 5.74 times faster when executing reflective code
    • To make the CLI a platform to directly support reflection
      • Semantics of the abstract machine should support reflective primitives
      • Extra code generation produces performance overhead (e.g., Jython and IronPython)
    • Structural Reflection is properly represented by an internal prototype-based model
      • plus a lazy schema evolution for classes
      • Both models could be supported (interaction)
    • Statically typed programs ( legacy code ) could be dynamically adapted
    • After many optimizations, static (non-reflective) member accesses performance cost has been reduced from 350% to 60%
      • Probably they can be reduced even more
    Conclusions
  • 30. Extending Rotor with Structural Reflection to support Reflective Languages