1 / 24

Managed Assertions : language-neutral behavioral contracts for components

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. Agenda. Introduction Language-neutral assertions & contracts System design and properties Implementation in Rotor

shoshana
Download Presentation

Managed Assertions : language-neutral behavioral contracts for components

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

  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. Typedef table owner name flag code inv. pre. Method table Figure 3. Contracts in CLI binary format Assertion table Implementation in Rotor (2/9)

  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

More Related