1. Managed Assertions : language-neutral behavioral contracts for components 2 nd Rotor Workshop 25 April 2003 Nam Tran Monash University nam.tran@mail.csse.monash.edu.au

2. Agenda Introduction Language-neutral assertions & contracts System design and properties Implementation in Rotor Wrap-up

3. 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

4. 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

5. 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

6. 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

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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

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

15. Implementation in Rotor (2/9) Typedef table Method table Assertion table ownernameflagcode inv. pre. Figure 3. Contracts in CLI binary format

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. Thank you! Q & A