topics covered in lecture:

1
Lecture 11

• topics covered in lecture
• introduction to .NET Framework
• similarities to Java Virtual Machine structure
  and use of bytecode

2
.NET Platform
3
.NET Platform

• 5 main components
• Visual Studio.NET - IDE supports 4 different
  languages, debugging and XML schema editor
• .NET Enterprise Servers - to reduce time to
  develop large scale business systems
• .NET Building Block Services - services
  application developers can use (for a fee)
• .NET Framework - runtime infrastructure - Common
  Language Runtime and common framework of classes
• O/S platform - normally Windows

4
.NET Framework - general features

• component support - improvement on COM - all
  classes can be re-used without additional coding
  - COM required additional code to allow software
  to fit as a component and COM did not permit
  language integration i.e. cannot reuse code in
  COM component - e.g. extend class or catch
  exception in code using component.
• Provides common target architecture for a number
  of languages - to support inter-operability of
  components in a distributed environment

5

• .NET Framework defines Common Type System (CTS) -
  everything is an instance of a class which
  ultimately inherits from root class called
  System.Object (like Java)
• CTS supports classes, interfaces, references,
  value types, delegates (which support call backs)
• .NET base classes support such things as integer,
  strings, file manipulation, etc.
• different languages can inter-operate because all
  compiled languages must meet Common Language
  Specification requirements and conform to CTS

6

• .NET Framework provides a set of common framework
  classes as an API for all languages - to deal
  with problem of having a variety of different
  APIs for different languages (common/standard API
  similar goal to Java class libraries)
• .NET Framework provides - common exception
  handling framework for all languages, garbage
  collection of the heap, runtime must recognise
  and verify classes before execution (sounds
  familiar -gtJava Virtual Machine)

7
.NET Framework
8

• Web Services - support development of lightweight
  distributed components, Web Forms - support
  development of web GUI applications, Window Forms
  - support development of native windows GUI
  applications
• Data and XML classes - support access to
  persistent data sources - principally databases
  and also XML data
• Framework Base classes - provides facilities
  similar to any basic API, MFC or Java libraries
  e.g. I/O, string handling, security, networking,
  threads, text, reflection, collections, etc.

9

• Common Language Runtime (CLR) - equivalent to JVM
  - loads and activates objects, verifies/security
  checks them, executes them and garbage collects.
• CLR supports all languages that can be
  represented in Common Intermediate Language
  (CIL).
• CIL is JIT compiled, but never interpreted (JVM
  nowadays uses JIT or hot-spot compiler - rarely
  interprets)

10

• Difference between CIL and Java bytecode -
  bytecode was primarily designed for specific
  language - Java, but to be multi-platform
  (although many languages can now be compiled into
  bytecode), CIL was designed for multiple
  languages (provided they met Common Language
  Specification) but primarily for MS Windows
  platform (MS have submitted Common Language
  Infrastructure (CLI) - functional subset of CLR
  to ECMA so that in theory third party vendor
  could write a CLI to run on separate platform,
  but .NET program executable IS a Windows native
  executable file - Windows IS the target platform.

11
Assemblies

• assembly is basic unit of deployment - consists
  of a manifest that describes the assembly
  contents, a set of modules (classes), and
  optional set of resources e.g. data files
• very similar to JavaBean component in a java jar
  (java archive file) file
• .NET assemblies are Portable Executable (PE)
  files
• these are .exe or .dll files that however consist
  mainly of metadata and code

12
PE file format

• MS Windows executable must conform to PE file
  format - derivative from Common Object File
  Format (COFF)
• standard PE files - organised into 2 sections
• first header section - info about content of file
• PE also contains a number of native image
  sections including .data, .rdata, .rsrc, .text
• standard executable format allows user defined
  sections to be added - using this functionality
  MS added new sections that are managed by CLR

13
Format of .NET PE file
14

• additional sections - CLR Header section and CLR
  Data sections - CLR Header indicates that PE file
  is a .NET file, CLR Data section contains
  metadata and IL code
• CLR Header imports mscoree.dll - main execution
  engine of CLR

15
metadata

• metadata - machine readable info about a resource
  (data about data)
• type defns, version info, external assembly
  refs., etc.
• type info includes method signatures, etc i.e.
  full interface specification in standardised form
• includes classes, interfaces, methods, fields,
  events, properties including security info,
  import and export info
• reflection class in base framework classes
  provide info about metadata

16
IL code

• IL code is Common Intermediate Language code - it
  is the target executable code for all languages
  that are compiled to run in .NET Framework
• IL - supports OO features - data abstraction
  (objects and classes), inheritance, polymorphism,
  exceptions and events
• supports reference types for objects, interfaces,
  arrays, strings, etc.
• actual object is held on a CLR managed garbage
  collected heap - internally a reference to object
  is passed around
• supports primitive value types like ints,
  doubles, booleans, etc. and for each primitive
  type there is an associated class type - like
  Java wrapper classes

17
CLR Virtual execution engine
18
CLR - execution

• CLR virtual execution system (VES)
• on top are PE files
• then class loader
• then JIT compilers - include verifier and JIT
  compiler itself
• then managed native code - this is code
  supported by garbage collection, security engine,
  code manager, exception manager, thread support,
  etc
• PE files go through loader, type verifier and JIT
  compiler before executing

19
class loader

• loads classes into memory and prepares them for
  execution
• loads any referenced classes
• initialises static vars. and instantiates object
  of the loaded class

20
verifier

• code is type-safe if code accesses types only in
  conformity with their type specification, and
  does not underflow/overflow system sensitive data
  structures like stacks, and handles exceptions
  and object initialisation correctly
• verifier checks to see if IL code is type-safe
  and performs some control flow analysis
• checks to see if metadata is well formed and
  valid
• verifier is part of JIT compiler and so is not
  used when class loaded, but only when a method is
  invoked

21
JIT compiler

• compiles one method at a time into managed native
  code I.e. execution support services are used
• JIT does mean that you can make CLR platform
  independent provided you have appropriate JIT
  compiler
• class loader generates a code stub for each
  method at load time
• at first invocation JIT reads stub and finds that
  no code has yet been generated for that method

22

• JIT compiler then compiles method and places
  address of managed native method code in the stub
• next time JIT reads stub it finds code already
  compiled and has address of native code
• can use tool to JIT compile all of code after
  loading and prior to invocation

23
Managed code - execution support

• JIT must also generate info the code manager
  needs to locate and unwind stack frames
• code manager uses managed data to control
  execution of the code including stack walks
  necessary for exception handling, security checks
  and garbage collection
• garbage collection - automatic lifetime
  management for heap objects - cleans resources
  when object no longer referenced
• exception handling - standard exception handling
  mechanism for all languages

24

• security - CLR perform security checks at runtime
  to ensure code is safe to execute and code not
  breaching any security requirements/policy
• debugging support
• interoperation support - CLR supports
  interoperation of CLR entities and unmanaged code
  - allowing .NET objects to use non .NET code and
  vice versa

25
System.Object

• root of all class hierarchies - default super
  class - has default public methods - very similar
  to Java
• Equals() - 2 objects have the same content
• ReferenceEquals() - are 2 object references
  referring to same object t
• GetHashCode() - returns object hashcode
• ToString() - string representation of object
• GetType() - returns object type - then use
  reflection API to find out about that class

26
Common Intermediate Code (CIL)

• CIL is an object oriented assembly language for a
  virtual stack-based machine - sounds familiar.
• Local variables are held in an array of locals,
  but different from JVM method parameters are held
  in separate argument array
• to add together 2 numbers
• IL_0000 ldloc.0
• IL_0001 ldloc.1
• IL_0002 add
• IL_0003 stloc.0
• ldloc.n - loads value at local var slot n onto
  stack
• add - adds 2 values on top of stack leaving
  result on stack
• stloc.n - stores value on top of stack into local
  var slot n

27
C Hello World in IL code

• .class private auto ansi beforefieldinit MainApp
  extends mscorlibSystem.Object
• .method public hidebysig static void Main() cil
  managed
• .entrypoint
• .maxstack 1
• IL_0000 ldstr c hello world!
• IL_0005 call void mscorlibSystem.ConsoleWrit
  eLine(string)
• IL_000a ret

28

• .method public hidebysig specialname
  rtspecialname instance void .ctor() cil managed
• .maxstack 1
• IL_0000 ldarg.0
• IL_0001 call instance void mscorlibSystem.Obje
  ct.ctor()
• IL_0006 ret

29
IL code - explanation

• auto - CLR perform automatic layout of this type
  at runtime
• ansi - CLR to use ansi string buffers to marshal
  data across managed and unmanaged boundaries
• cil managed means that code can be executed by
  CLR
• hidebysig - means this method hides method of
  same signature in super classes - default
  behaviour in most OO languages
• .instr - these are directives to CLR about class
  or methods not instructions to be executed

30

• .entrypoint specifies that this is the one and
  only entry point for execution for this assembly
• .maxstack specifies maximum stack slots needed
  for this method
• ldstr - loads reference to string object onto the
  stack
• call invokes WriteLine method - call expects to
  find the method parameter values on the stack -
  param order is same as pushing order on the stack
  - also need to specify method signature of method
  that you call (inc enclosing class)

31

• WriteLine() is method in Console class that
  belongs to system namespace that is part of
  mscorlib assembly
• ret - returns control to caller
• ctor() is the default constructor for the class -
  same role as ltinitgt() in JVM
• instance - indicates non-static method
• it loads an argument from 0th position in
  argument array - ldarg.0
• then calls constructor for super class

32

• public class Point
• public double x
• public double y
• class App
• static void Main()
• Point p new Point()
• p.x 12
• p.y 24

Another example - C code for simple class
33
IL code for Point class - this and next slide

• .class public auto ansi beforefieldinit Point
  extends mscorlibSystem.Object
• .field public float64 x
• .field public float64 y
• .class private auto ansi beforefieldinit App
  extends mscorlibSystem.Object

34

• .method private hidebysig static void Main() cil
  managed
• .entrypoint
• .maxstack 2
• .locals init (class Point V_0)
• IL_0000 newobj instance void Point.ctor()
• IL_0005 stloc.0
• IL_0006 ldloc.0
• IL_0007 ldc.r8 12.
• IL_0010 stfld float64 Pointx
• IL_0015 ldloc.0
• IL_0016 ldc.r8 24.
• IL_001f stfld float64 Pointy
• IL_0024 ret

35

• new instructions
• .field - declares a class field
• float64 - 64 bit floating point type (other types
  include int32, etc)
• .locals - identifies local vars used
• newobj - creates an instance of class type
  specified - leaving object reference on stack
• stfld - stores value on top of stack in field of
  object whose reference is next entry on stack -
  requires field type signature
• ldc - load constant value onto stack - the .r8
  indicates that the value is to held on the stack
  as a 8 byte (64 bit) value

36
.NET Framework JVM

• The following are striking similarities between
  JVM and .NET Framework
• structure of programmers model of virtual machine
  and instruction set
• Object oriented languages features supported
• Runtime support facilities e.g. garbage collected
  heap
• the provision of a common API for high level
  language code portability
• provision of JIT compilation onto native machine