Managed Assertions language-neutral behavioral contracts for by vow15418


									Managed Assertions: language-neutral
    behavioral contracts for components

            2nd Rotor Workshop
               25 April 2003

                                                Nam Tran
                                         Monash University
 Language-neutral assertions & contracts
 System design and properties
 Implementation in Rotor
  Rotor project at Monash university
     Advisors: Prof. David Abramson, Prof. Christine
     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
Language-neutral contracts: again?
            Source with assertions               Normal source                          Assertion specs

             Augmented compiler                 Normal compiler                       Assertion compiler   Common binary

                               Contracted                           Contracted
                               components                           components

treatment                  Managed assertion                      Garbage collector

                          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
        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
        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 {
               enum {
                    COL_TargetRVA,   // target of general check
                    COL_Flags,       // what kind of assertion
                    COL_Owner,       // owner type or method
                    COL_Eval,        // evaluation method
Implementation in Rotor (2/9)
    Typedef table

                                  owner         name           flag    code


    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
        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
        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
        Ensure that no assertion exceptions are
        accidentally caught by callee code
     Adjust max stack value as appropriate
 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!

To top