Managed Assertions language-neutral behavioral contracts for by vow15418

VIEWS: 4 PAGES: 24

									Managed Assertions: language-neutral
    behavioral contracts for components

            2nd Rotor Workshop
               25 April 2003


                                                Nam Tran
                                         Monash University
                         nam.tran@mail.csse.monash.edu.au
Agenda
 Introduction
 Language-neutral assertions & contracts
 System design and properties
 Implementation in Rotor
 Wrap-up
Introduction
  Rotor project at Monash university
     Advisors: Prof. David Abramson, Prof. Christine
      Mingins
     Related: Guard.NET, Eiffel.NET
  Motivation from Common Type System
     Language neutral typing semantics
  Motivation from Design by Contract
     Behavioral contracts
  Rotor for its multi-language components
Language-neutral contracts: why?
  Components are inherently language-neutral
  Components integration requires precise
  interfaces (contracts)
     more than just typing contracts (syntactic)
     behavioral contracts
  Need for a language-neutral contracts system
     Similar in spirit to the common type system
Language-neutral contracts: what?
  Behavioral component contracts
     Interface invariants
     Method pre- and post-conditions
     Assertions on visible state
  Common contract system
     Common designated meaning of constructs
     Common binary representation
     Common runtime treatment
Language-neutral contracts: how?

  Managed assertions
     Assertions are first class constructs
     Binary format neutral of source syntax
        represented separately from program code
     Assertions checking is managed
        runtime service understands assertions
        decisions to check assertions are made at
        runtime
Language-neutral contracts: again?
            Source with assertions               Normal source                          Assertion specs




             Augmented compiler                 Normal compiler                       Assertion compiler   Common binary
                                                                                                           representation



                               Contracted                           Contracted
                               components                           components


 Common
 runtime
treatment                  Managed assertion                      Garbage collector
                               runtime




                          Runtime
                          System               Just-in-Time compiler




                               Figure 1. Managed assertions system architecture
Design and properties (1/6)
  Common representation
     Assertions are compiled to code blocks
     Separate from method bodies
     Roles are designated explicitly by metadata
     Properties
        contracts become part of binary components
         but remain first class entities
        flexibility in checking policies
        enabling correct and efficient dynamic checks
Design and properties (2/6)
  Native runtime support
     enforcement policies checked at runtime
     runtime service collects and executes
      assertions
        follows metadata designation
        relies on dynamic dispatch resolution
        walks subtyping hierarchies
Design and properties (3/6)
  Runtime support properties
     Behavioral subtyping rules
        subtype’s pre-condition implied by base type’s
        subtype’s post-condition implies base type’s
     Upheld by
        specification of partial conditions, e.g. require
         and require else
        runtime combinations via OR and AND for pre-
         and post-conditions, respectively
Design and properties (4/6)
  Runtime support properties (cont.)
     Exception handling
        Pre-condition violation raised to caller
        Post-condition violation indicates (to caller)
         callee’s fault
        Invariant violation indicates (to caller)
             callee’s fault if upon method return
             prior error if upon method entry
Design and properties (5/6)
  Runtime support properties (cont.)
     Object re-entrance
        invariants checking of external calls prevents
         dangerous re-entrant calls
        internal calls are allowed to temporarily break
         invariants
        indirect external re-entrant calls are still
         subjected to invariants checking
        enabling flexible implementation while
         regulating external interactions
Design and properties (6/6)
  Runtime support properties
     Reflection
        Assertions are first class entities
        Assertion objects can be constructed and
         retrieved at runtime
        Enabling possible classes of tools
             verifiers to check contract at load-time
             adapters to liaise between components
Implementation in Rotor (1/9)
  Binary representation
     Named assertions are special methods
     Assertions metadata table
     Table number 0x2a: mdtAssertion = 0x2a000000
           class AssertionRec {
           public:……
               enum {
                    COL_TargetRVA,   // target of general check
                    COL_Flags,       // what kind of assertion
                    COL_Owner,       // owner type or method
                    COL_Eval,        // evaluation method
                    COL_Name,
               };
           }
Implementation in Rotor (2/9)
    Typedef table




                                  owner         name           flag    code


                                                                inv.




                                                                pre.
    Method table




                                                   Assertion table




                    Figure 3. Contracts in CLI binary format
Implementation in Rotor (3/9)
  Runtime support
     Extensions to metadata interfaces, classes
        IMetaDataEmit, IMetaDataImport
        RegMeta and related classes
        No extensions to managed APIs yet
     Checking policies
        Configuration facility extension
        Object identities check to see if caller and
        callee are the same object for invariant checks
Implementation in Rotor (4/9)
  Runtime checking concerns
     Correctness (subtyping, dynamic dispatch)
     Sensible exception handling
     Least overhead
  Runtime checking choices
     Native stubs
     Extra wrapper method
     Inlined wrapping
Implementation in Rotor (5/9)
  Runtime checking of assertions
     Perform IL body re-writing
     Weave checking code into callee method
     Just before a method is JIT-compiled
     Replace method body using profiling APIs
     But does not go through external interface
        Improve efficiency and leaving the interface for
        user code profiler
Implementation in Rotor (6/9)
  IL body re-writing
     Create extra local variables if necessary
        one to hold return value if non-void
     To check pre-conditions
        Collect and inline all relevant pre-condition
         methods
        Jump to exception raising code if all resultant
         boolean are false
Implementation in Rotor (7/9)
  IL body re-writing (cont.)
     Inline old body
        Replace ‘return’ by assignment and jump
             Assignment to extra local variable
             Jump to label after end of old body
Implementation in Rotor (8/9)
  IL body re-writing (cont.)
     To check post-conditions
        Collect and inline all relevant post-condition
         methods
        Jump to exception raising code if any resultant
         boolean is false
        Return normally otherwise
     Invariant checks code weaving is similar
Implementation in Rotor (9/9)
  IL body re-writing (cont.)
     Adjust exception tables to reflect offset
      changes
        Ensure that no assertion exceptions are
        accidentally caught by callee code
     Adjust max stack value as appropriate
Wrap-up
 What’s next
     Complete implementation
       Modifications to ILASM/ILDASM
            Extra textual IL syntax constructs for assertions
       Modifications to source compilers
            Adopt/create source assertion notation
            Eiffel.NET to compile to new format
            C# compiler
Thank you!
   Q&A

								
To top