210 likes | 376 Views
The Execution System. Introduction. Managed code and managed data qualify code or data that executes in cooperation with the execution engine The execution system is the part of the CLR that is responsible for the controlled execution of programs that contain managed code
E N D
The Execution System The Execution System
Introduction • Managed code and managed data qualify code or data that executes in cooperation with the execution engine • The execution system is the part of the CLR that is responsible for the controlled execution of programs that contain managed code • loading assemblies, controlling execution flow, and managing the garbage collection • Executes CLR programs, utilizing the metadata to perform such services as memory management • Provides a safe and secure environment for execution • A primary goal for it was that is not be tied to any specific hardware or software platform. Make no assumptions about the hardware architecture or OS services. • This flexibility makes porting the CLR to other systems easier. The Execution System
Key elements in the .NET Execution System • Execution environment • Intermediate language (IL) • Just-in-time (JIT) compilation & verification • Application domains • Memory management & Garbage Collection • Security • Security Models • Policy Manager • Stack Walks The Execution System
Intermediate Language (1) • Source -> Intermediate Language -> native code • Compilers that target the CLR translates their source code into Common Intermediate Language (CIL) • CIL is often described as an object-oriented assembly language for an abstract stack-based machine • Independent of any specific hardware architecture • Translation from IL to native code can be accomplished at any stage up to execution of the code • Just-In-Time (JIT) Compilation The Execution System
JIT (1) The Execution System
JIT (2) The Execution System
JIT (3) The Execution System
Execution Environment & JIT Compilation • Virtual Machine concept • An abstract execution environment • Independent of hardware platform • JIT compilation (or even at install time), never interpreted The Execution System
Intermediate Language (2) using System; namespace SampleIL { class EntryPoint { private static int Add(int a, int b) { return a + b; } static void Main(string[] args) { int a = 40; int b = 2; int c = Add(a, b); Console.WriteLine("Total is: {0}", c); } } } .method private hidebysig static void Main(string[] args) cil managed { .entrypoint // Code size 30 (0x1e) .maxstack 2 .locals init ([0] int32 a, [1] int32 b, [2] int32 c) IL_0000: ldc.i4.s 40 IL_0002: stloc.0 IL_0003: ldc.i4.2 IL_0004: stloc.1 IL_0005: ldloc.0 IL_0006: ldloc.1 IL_0007: call int32 SampleIL.EntryPoint::Add(int32, int32) IL_000c: stloc.2 IL_000d: ldstr "Total is: {0}" IL_0012: ldloc.2 IL_0013: box [mscorlib]System.Int32 IL_0018: call void [mscorlib]System.Console::WriteLine(string, object) IL_001d: ret } // end of method EntryPoint::Main The Execution System
Verification of Intermediate Language • Remote, downloaded, mobile code may be dangerous, having viruses, misbehaved • In Java, they use a ‘sandbox’ approach • In .NET, they use a ‘type safety’ concept • Undergoes a pre-execution inspection on the assembly to check if it is type-safe • Two tasks • Checking for the assembly itself – the manifest • Checking for types the assembly contains • Verification process occurs during the JIT compilation • It forms the first part of security on the CLR. The Execution System
Starting a CLR Program • An executable CLR program contains at least three components • The user-defined assembly with an entry point • The execution system, found in either mscorsvr.dll or mscorwks.dll • The basic type system, found in mscorlib.dll • May need to access types defined in other assemblies The Execution System
Application Domains (1) • Process – program in execution • Processes are expensive in terms of resource usage • Application domains – concept like subprocesses within a process, require less overhead • Execution system manages the application domains instead of multiple processes The Execution System
Process ApplicationDomain ApplicationDomain Assembly Assembly Module Module Module Application Domains (2) • An assembly is always loaded into an application domain • Assemblies can also be domain-neutral, shared among application domains, e.g. mscorlib • References cross domain boundaries are subject to constraints • A process may contain one or more application domains • An application domain may contain one or more assemblies • An assembly may contain one or more modules An executing CLR application The Execution System
Memory Management • CLR provides automatic memory management (allocating and freeing the memory) • Advantages of automatic memory management • Programmer no need to release memory explicitly • Ensure that while a object has a reference to it, its memory will not be reclaimed • Ensure that once an object becomes unreachable, its memory will be reclaimed (Garbage Collection) • Value Types • Allocated on program stack, remains available until the method returns • Reference Types • Allocated on heap, lifetimes not related to the methods that create them The Execution System
Garbage Collection • Objects are allocated on the Managed Heap which is a large area of memory • At some point during program execution, CLR (the Garbage Collector) may start reclaiming the memory allocated for unreachable objects • Can be triggered by calling GC.Collect(), or by the runtime noticing that free memory in heap is low The Execution System
Security System • CLR’s security system provides two different security models • Role-based security system • Based on concepts of identities (users) and roles (groups) • Evidence-based security system • Based on code, and is designed to provide security for mobile and downloaded code The Execution System
Role-based Security • Identity – represents the user on whose behalf the code is executing, could be a logical user as defined by the application or developer • Principal – represents the abstraction of a user and the roles in which he/she belongs • At runtime, each thread has one and only one current Principal object, each Principal has one and only one Identity object • Application can limit access based on these information (Listing 4.3, 4.4) The Execution System
Evidence-based Security • Evidence-based security assigns permissions to assemblies based on evidence. • It uses the location (e.g. URL, directory etc.) from which executable code is obtained as a primary factor in determining which resources the code should be able to access • Whenever an assembly is loaded into CLR for execution, the hosting environment attaches the evidence to the assembly, the security system then map this evidence into a set of permissions, which will determine the code’s access to resources. The Execution System
Policy Manager (1) • The Policy Manager determines permissions based on the evidence supplied to it. Four policy levels • Enterprise • Machine • User • Application Domain • The overall permission is the ‘intersection’ of permissions of these levels The Execution System
Hosting Environment Common Language Runtime Assembly Assembly Policy Manager Permission Set Evidence Policy Levels Enterprise Machine User Security Settings Application Domain Policy Manager (2) The Execution System
Stack Walks • A new activation record is put on the stack every time a method is called, it contains the parameters passed, the address to return, and local variables. • During execution, the thread may seek to access a system resource and the security system may demand a Stack Walk to verify that all functions in the call chain have permission to access the resource. • A Stack Walk is an essential, but expensive, feature of the security system. The Execution System