manipulating managed execution manipulating managed
play

Manipulating Managed Execution Manipulating Managed Execution - PowerPoint PPT Presentation

Manipulating Managed Execution Manipulating Managed Execution Runtimes to support Self-Healing Runtimes to support Self-Healing Systems Systems Rean Griffith, Gail Kaiser Rean Griffith, Gail Kaiser Presented by Rean Griffith


  1. Manipulating Managed Execution Manipulating Managed Execution Runtimes to support Self-Healing Runtimes to support Self-Healing Systems Systems Rean Griffith‡, Gail Kaiser‡ Rean Griffith‡, Gail Kaiser‡ Presented by Rean Griffith Presented by Rean Griffith rg2023@cs.columbia.edu rg2023@cs.columbia.edu ‡ - Programming Systems Lab (PSL) Columbia University ‡ - Programming Systems Lab (PSL) Columbia University 1 1

  2. Introduction Introduction 2 2

  3. Overview Overview • Motivation Motivation • Managed Execution Model Managed Execution Model • System Architecture System Architecture • How it works How it works • Performing a repair Performing a repair • Performance Performance • Conclusions & Future work Conclusions & Future work 3 3

  4. Motivation Motivation • Managed execution environments e.g. JVM, CLR Managed execution environments e.g. JVM, CLR provide a number of application services that provide a number of application services that enhance the robustness of software systems, enhance the robustness of software systems, BUT… BUT… • They do not currently provide services to allow They do not currently provide services to allow applications to perform consistency checks or applications to perform consistency checks or repairs of their components repairs of their components • Managed execution environments intercept Managed execution environments intercept everything applications running on top of them everything applications running on top of them attempt to do. Surely we can leverage this attempt to do. Surely we can leverage this 4 4

  5. Managed Execution Model Managed Execution Model Execute // Other code Application/Module Find member 1 SampleClass s = new SampleClass(); Load doSomethingUseful() s.doSomethingUseful(); in memory // More code 2 Class Load Method No Do JIT-Compile body JIT 3 Method Invoke of Bytecode Compiled? Yes JIT Compile 4 (if necessary) Jump to JIT-Compiled native assembly version of the method 5 Function Enter 6 Function Exit 5 5

  6. Runtime Support Required Runtime Support Required Facility CLR v1.1 JVM v5.0 The ability to receive notifications Profiler JVMTI about current execution stage API (no JIT) The ability to obtain information Yes Yes (metadata) about the application, types, methods etc. from profiler The ability to make controlled Fine- Coarse- changes or extensions to metadata grained grained e.g. new function bodies, new type, (full) (partial) type::method references The ability to have some control Yes No over the JIT-Compilation process 6 6

  7. System Architecture System Architecture 7 7

  8. Our Prototype’s Model of Operation Our Prototype’s Model of Operation Execution Runtime Augment type metadata Application/Module 1 e.g. define new method stubs as Load repair-engine hooks 2 Class Load 3 Method Invoke Fill in method stubs, edit/replace JIT Compile method body, insert jumps into 4 (if necessary) repair engine, undo changes 5 Function Enter RepairEngine::RepairMe(this) Repair/Consistency check 6 Function Exit 8 8

  9. Phase I – Preparing Shadow Phase I – Preparing Shadow Methods Methods • At module load time At module load time Before After but before type but before type definition installed definition installed Bytecode Bytecode – Extend type Extend type method method metadata by body body metadata by defining with new defining with new methods which will methods which will be used to allow a be used to allow a repair engine to repair engine to SampleMethod SampleMethod _SampleMethod interact with interact with RVA RVA RVA instances of this instances of this type type 9 9

  10. Phase II – Creating Shadow Phase II – Creating Shadow Methods Methods • At first JIT- At first JIT- Before After New Compilation Compilation Bytecode method Bytecode Bytecode – Define the body Define the body body method method body body of the shadow of the shadow Call _Sample method and re- method and re- Method wire some wire some things under- things under- SampleMethod _SampleMethod SampleMethod _SampleMethod RVA RVA RVA RVA the-hood the-hood SampleMethod( args ) <room for prolog> push args call _SampleMethod( args ) <room for epilog> return value/void 10 10

  11. Performing a Repair Performing a Repair • Augment the wrapper to insert a jump into a Augment the wrapper to insert a jump into a repair engine at the control point(s) control point(s) before before repair engine at the and/or after a shadow method call and/or after a shadow method call SampleMethod( args ) RepairEngine::RepairMe(this) push args call _SampleMethod( args ) RepairEngine::RepairMe(this) return value/void 11 11

  12. Performance – No Repairs Active Performance – No Repairs Active 12 12

  13. Overheads on the Managed Overheads on the Managed Execution Cycle Execution Cycle 13 13

  14. Contributions Contributions • Framework for dynamically attaching/detaching Framework for dynamically attaching/detaching a repair engine to/from a target system a repair engine to/from a target system executing in a managed execution environment executing in a managed execution environment • Prototype which targets the Common Language Prototype which targets the Common Language Runtime (CLR) and supports this dynamic Runtime (CLR) and supports this dynamic attach/detach capability with low runtime attach/detach capability with low runtime overhead (~5%) overhead (~5%) 14 14

  15. Limitations Limitations • Repairs can be scheduled but they depend on Repairs can be scheduled but they depend on the execution flow of the application to be the execution flow of the application to be effected effected – Deepak Gupta et al. prove that it is un-decidable to Deepak Gupta et al. prove that it is un-decidable to automatically determine that “now” is the right time for a repair automatically determine that “now” is the right time for a repair – Programmer-knowledge is needed to identify “safe” control- Programmer-knowledge is needed to identify “safe” control- points at which repairs could be performed points at which repairs could be performed – The “safe” control points may be difficult to identify and may The “safe” control points may be difficult to identify and may impact the kind of repair action possible impact the kind of repair action possible • Primarily applicable to managed execution Primarily applicable to managed execution environments environments – Increased metadata availability/accessibility Increased metadata availability/accessibility – Security sandboxes restrict the permissions of injected bytecode Security sandboxes restrict the permissions of injected bytecode to the permissions granted to the original application to the permissions granted to the original application 15 15

  16. Conclusions & Future Work Conclusions & Future Work • Despite being primarily applicable to managed Despite being primarily applicable to managed execution environments, these techniques may execution environments, these techniques may help us “Watch the Watchers” help us “Watch the Watchers” – the management infrastructure we are building is the management infrastructure we are building is likely to be written in managed code (Java, C#) likely to be written in managed code (Java, C#) running in the JVM, CLR mainly because these running in the JVM, CLR mainly because these environments provide application services that environments provide application services that enhance the robustness of managed applications enhance the robustness of managed applications • On the to-do list: On the to-do list: – Continue working on the prototype for the JVM so we Continue working on the prototype for the JVM so we can compare the performance and generalize the can compare the performance and generalize the runtime support requirements listed earlier runtime support requirements listed earlier – Do a real case study to see what issues we run into Do a real case study to see what issues we run into with respect to identifying and leveraging “safe” with respect to identifying and leveraging “safe” control points, the implications of architectural style control points, the implications of architectural style 16 16

  17. Comments, Questions, Queries Comments, Questions, Queries Thank You Thank You Contact: rg2023@cs.columbia.edu Contact: rg2023@cs.columbia.edu 17 17

  18. Extra slides Extra slides 18 18

  19. Motivation Motivation Un-managed Managed Managed Self-healing execution execution execution systems + Execution Environment extensions • Managed execution environments e.g. JVM, CLR provide Managed execution environments e.g. JVM, CLR provide a number of application services that enhance the a number of application services that enhance the robustness of software systems BUT… robustness of software systems BUT… • They do not currently provide services to allow They do not currently provide services to allow applications to perform consistency checks or repairs of applications to perform consistency checks or repairs of their components their components • Managed execution environments intercept everything Managed execution environments intercept everything applications running on top of them attempt to do. applications running on top of them attempt to do. Surely we can leverage this Surely we can leverage this 19 19

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend