Manipulating Managed Execution Manipulating Managed Execution - - PowerPoint PPT Presentation

▶
manipulating managed execution manipulating managed
SMART_READER_LITE
LIVE PREVIEW

Manipulating Managed Execution Manipulating Managed Execution - - PowerPoint PPT Presentation

Jan 22, 2024 47 likes •253 views

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

slide-1
SLIDE 1

1 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
slide-2
SLIDE 2

2 2

Introduction Introduction

slide-3
SLIDE 3

3 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

slide-4
SLIDE 4

4 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

slide-5
SLIDE 5

5 5

Managed Execution Model Managed Execution Model

// Other code SampleClass s = new SampleClass(); s.doSomethingUseful(); // More code Find member doSomethingUseful() in memory Jump to JIT-Compiled native assembly version

  • f the method

Method body JIT Compiled? Do JIT-Compile

  • f Bytecode

Execute Yes No Application/Module Load Class Load Method Invoke JIT Compile (if necessary) Function Exit Function Enter

1 2 3 4 5 6

slide-6
SLIDE 6

6 6

Runtime Support Required Runtime Support Required

JVM v5.0 CLR v1.1 Facility No Yes The ability to have some control

  • ver the JIT-Compilation process

Coarse- grained (partial) Fine- grained (full) The ability to make controlled changes or extensions to metadata e.g. new function bodies, new type, type::method references Yes Yes The ability to obtain information (metadata) about the application, types, methods etc. from profiler JVMTI (no JIT) Profiler API The ability to receive notifications about current execution stage

slide-7
SLIDE 7

7 7

System Architecture System Architecture

slide-8
SLIDE 8

8 8

Our Prototype’s Model of Operation Our Prototype’s Model of Operation

Application/Module Load Class Load Method Invoke JIT Compile (if necessary) Function Exit Function Enter

1 2 3 4 5 6

Augment type metadata e.g. define new method stubs as repair-engine hooks

Execution Runtime

Fill in method stubs, edit/replace method body, insert jumps into repair engine, undo changes RepairEngine::RepairMe(this) Repair/Consistency check

slide-9
SLIDE 9

9 9

Phase I – Preparing Shadow Phase I – Preparing Shadow Methods Methods

  • At module load time

At module load time but before type but before type definition installed definition installed

– Extend type Extend type metadata by 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 interact with interact with instances of this instances of this type type

SampleMethod RVA Bytecode method body _SampleMethod RVA

After

SampleMethod RVA Bytecode method body

Before

slide-10
SLIDE 10

10 10

Phase II – Creating Shadow Phase II – Creating Shadow Methods Methods

  • At first JIT-

At first JIT- Compilation Compilation

– Define the body Define the body

  • f the shadow
  • f the shadow

method and re- method and re- wire some wire some things under- things under- the-hood the-hood

SampleMethod RVA Bytecode method body _SampleMethod RVA

Before

SampleMethod RVA New Bytecode method body Call _Sample Method _SampleMethod RVA

After

Bytecode method body SampleMethod( args ) <room for prolog> push args call _SampleMethod( args ) <room for epilog> return value/void

slide-11
SLIDE 11

11 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 repair engine at the control point(s) control point(s) before before 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

slide-12
SLIDE 12

12 12

Performance – No Repairs Active Performance – No Repairs Active

slide-13
SLIDE 13

13 13

Overheads on the Managed Overheads on the Managed Execution Cycle Execution Cycle

slide-14
SLIDE 14

14 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

  • verhead (~5%)
  • verhead (~5%)
slide-15
SLIDE 15

15 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

slide-16
SLIDE 16

16 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

slide-17
SLIDE 17

17 17

Comments, Questions, Queries Comments, Questions, Queries

Thank You Thank You

Contact: rg2023@cs.columbia.edu Contact: rg2023@cs.columbia.edu

slide-18
SLIDE 18

18 18

Extra slides Extra slides

slide-19
SLIDE 19

19 19

Motivation Motivation

Un-managed execution Self-healing systems Managed execution Managed execution + 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

slide-20
SLIDE 20

20 20

Our Prototype’s Model of Operation Our Prototype’s Model of Operation

Application/Module Load Class Load Method Invoke JIT Compile (if necessary) Function Exit Function Enter

1 2 3 4 5 6

Augment type metadata e.g. define new method stubs as repair-engine hooks

Execution Runtime

Fill in method stubs, edit/replace method body, insert jumps into repair engine, undo changes Metadata extensions e.g. add references to new modules, types and methods RepairEngine::RepairMe(this) Repair/Consistency check JIT-Control API e.g. request method re-JIT