Managed Assertions : language-neutral behavioral contracts for components

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

Common binary representation Source with assertions Normal source Assertion specs Augmented compiler Normal compiler Assertion compiler Contracted components Contracted components Runtime System Managed assertion runtime Garbage collector Just-in-Time compiler Figure 1. Managed assertions system architecture Language-neutral contracts: again? Common runtime treatment

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, }; }

Typedef table owner name flag code inv. pre. Method table Figure 3. Contracts in CLI binary format Assertion table Implementation in Rotor (2/9)

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

Managed Assertions : language-neutral behavioral contracts for components