1 / 11

Type Safety for Systems Programming

By: Bryan Dixon. Type Safety for Systems Programming. Needs for a Systems PL. Performance Explicit Memory Management Fine-grained control over assembly level data representation. What’s wrong with…?. C/C++ Lacks any sort of structure to ensure type safety and safe memory usage. Java

april
Télécharger la présentation

Type Safety for Systems Programming

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. By: Bryan Dixon Type Safety for Systems Programming

  2. Needs for a Systems PL • Performance • Explicit Memory Management • Fine-grained control over assembly level data representation

  3. What’s wrong with…? • C/C++ • Lacks any sort of structure to ensure type safety and safe memory usage. • Java • Lacks performance and explicit memory/low level details needed.

  4. Options? • Create a new language with these language features in mind • Check existing C code at compile/runtime for possible type/memory issues than can arise. • Create an extension of the C language to add these extra languages features/checks

  5. Compiler Extensions • Similar to a compiler extension to enforce ANSI C style • Can formally check statically at compile time for type safety • Add dynamic runtime checks to check for memory safety at runtime. • Doesn’t require you to change legacy code.

  6. SafeC • A type of compiler extension for type safety • Does its checking by adding runtime extensions to existing code to ensure safety • Requires almost no changes in existing code • No formal soundness to the safety provided • 130%-540% performance overhead

  7. CCured • Unlike dynamic type safety checking like SafeC, also does static type checking at compile time, limiting the pointers/types that need to be monitored at runtime • Some drawbacks on the safety that CCured forces on memory management that make it lack some explicit memory management functionality desired as a systems level language • 30% -150% performance overhead

  8. A few more • Deputy/Ivy: From Berkley and are similar to the other two though slightly different implementations • May require new includes in legacy code • Likely similar performance overhead of CCured, as they perform static type analysis or use type annotations to reduce the need to do all the type checks at run time.

  9. Expanded C (Cyclone) • Similar to C syntax but new syntax to better support type safety • Cyclone has added support for type-safety in multi-threaded processes. • Slight modifications to existing code possibly needed, though most code will not need modification • 0-150% performance improvement

  10. New Language (Vault) • Best solution if you wanted to rewrite everything from scratch • You can’t make use of any/all legacy code • Likely to be the best solution for performance. • Best example is Vault, vault currently unsafe in multithreaded processes. • Likely similar performance to that of Cyclone

  11. Summary • No perfect solution currently, lots of overhead and may require changes to existing code to make it type safe or even completely rewriting code to a new language syntax • If I had to make a choice of current options would choose Cyclone as it offers better performance with the least overhead and offers support in a recent release for multithreading.

More Related