High-Level Language Virtual Machine Architecture

Contents
Introduction of HLL VM The Pascal P-code VM Object-Oriented HLL VM Java VM Architecture

HLL program characteristics

Platform dependence Library, OS system call, ISA Porting to another platform, At least re-compile Rewrite build environment
compiler, library, assembler, linker, etc.
HLL Program Library of HLL OS Hardware

Modify source code ( e.g., system call ) Painful for S/W venders

Employ process VM to avoid porting Emulating applications ISA and OS calls Difficult to emulate some OS interfaces completely High-performance is hard to achieve
3

HLL VM
New design of ISA/interface with VM-based portability
Generic ISA free of implementation-specific features Abstracted system interface easily supported by OS Support for target HLL such as OO languages Compared to process VM,
Supports virtual ISA (V-ISA) Interface based on standard libraries (API) for network, file, graphics

V-ISA includes data specification as well as instruction set

Important for platform independency data set architecture than instruction set architecture

HLL VMs from Language Perspectives

HLL program
Compiler frontend

HLL program
Compiler frontend

Intermediate code
Compiler backend

Portable code (Virtual ISA) distributed

VM loader

Object code (Real ISA)

Loader

Virtual memory image

VM interpreter or translator

Memory image

Host instruction

Usual programming language implementation

Another programming language implementation

And another implementation

Overview
Source code is translated into an intermediate representation, (IR) The IR can be processed in these different ways:
1. compile-time (static) translation to machine code 2. emulation of the IR using an interpreter 3. run-time (dynamic) translation to machine code = JIT (Just-In-Time) compiling

What is IR? IR is code for an idealized computer, a virtual machine.

Examples:Language IR Implementation(s)

Language

IR

Implementation

Java C#
Pascal

JVM bytecode MSIL

p- code --

Interpreter, JIT JIT

Interpreted compiled compiled

C, C++

--

10

JVM
Major components
Class loader subsystem Memory system
Including garbage-collected heap

Emulation engine

11

Java VM Architecture
Java VM is for executing Java programs
Usually referred to as Java Runtime Environment (JRE) Contains the Java virtual machine, classes comprising the Java 2 Platform API, and supporting files JDK (Java development kit): JRE, Development Tools (compiler, debugger), additional library

a.java

b.java Java compiler

c.java

a.class

b.class

c.class

JVM
c.class Object.class String.class
12

a.class

b.class

Data accessing

13

Data movement: through stack onl y

14

Run-Time Data Areas

15

Runtime Data Area

Method area, heap, stack, PC registers

16

Memory regions
Each time a class is loaded, info about the class is copied into t he method area. While a program is running, all instantiated objects (instances of classes, arrays) are allocated on the heap. When a new thread comes into existence, it gets its own Java stack and its own pc register. The pc register indicates which JVM instruction to execute next in a methods bytecode. The Java stack contains all the state information for a thread The state of native method invocations is held in a native method stack.
17

Dynamic class loading

Class loader subsystem Convert the class file into an implementationdependent memory image Find binary classes Verify correctness and consistency of binary classes Part of the security system
How can we identify methods, variables, and other data items ? Standard and universal way is needed Fully qualified name Ex) edu.wisc.ece.jes.testpackage.shape.area
18

19

 Class loaders
Primordial class loader
Defined as part of the JVM specification Trusted JVM component

User-defined class loader

Trusted as the user who supplies the loader

For security
Separate namespace
Barrier between the different namespaces Tag loaded classes
20

The Method Area

Contains one entry for each class Lists all details relating to that class Includes the constant pool Contains the code for the methods May grow/shrink as classes are loaded/ unloaded Shared by all threads.
21

The Heap
One entry for each object Increases with each instance creation Decreases with garbage collection (mec hanism not specified) Object information: instance field values, pointer to class Shared by all threads.
22

Java Stack
JVM pushes and pops frames onto this stack Each frame corresponds to the invocation of a method Call a method push its frame onto the stack Return from a method pop its frame Frame holds parameter values, local variables, intermediate values etc.
23

 Garbage collector
Reclaim heap memory no longer needed Included in most JVM implementations

Emulation engine
Supported by the native method interface & implied registers Can be interpreter or translator
24

 Native method interface

To access OS-managed functions
Ex) file I/O, graphics

To bridge the gap between the platformindependent and platform-dependent parts of the overall system

25

Example
Consider a bytecode sequence that corresponds to i = (j + 2) * (k - 2); The byecode is similar to this (using symbolic names and constant values instead of indexes):
iload j ldc 2 iadd iload k ldc 2 isub imul istore i
26

Example Contd

27

Data Types
Primitive data types
int, char, byte, short, float, double

Reference type
Hold a reference value or null

Objects
Carry data declared by the class Composed of primitive data or references to other objects array is a special object with ISA support

28

Data types

29

Load and Store Instructions

Transferring values between local variables and operand stack
iload, lload, fload, dload, aload istore, lstore, fstore, dstore, astore

Pushing constants onto the operand stack

bipush, sipush, ldc, ldc_w, ldc2_w, aconst_ null, iconst_m1 and special cases: iconst_0, const_1, ...
30

Arithmetic Operations
Operands are normally taken from operan d stack and the result pushed back there
iadd, ladd, fadd, dadd isub ... imul ... idiv ...

31

HLL VM Examples
Pascal VM with a V-ISA called P-code Java VM with a V-ISA called bytecode Common language infrastructure (CLI) in .NET platform with a V-ISA called MSIL

32

The Pascal P-Code VM

P-code is a simple, stack-based ISA Only one Pascal compiler needs to be developed
Distributed as a P-code version

Porting Pascal is implementing the VM only

Much simpler than writing a Pascal compiler for the platform
Pascal Program binary Library of Pascal OS Hardware Pascal Program P-code

Pascal P-code VM (P-code emulator, Library)

Platform( OS, Hardware, etc)
33

Memory Architecture
Program memory, constant area, stack, and heap
All data areas are divided into cells,
Each cell can hold a single value Actual size of cell is implementation dependent but large enough

Constant area (immediate operands) A stack

Procedure stack Operand stack for instruction execution

No garbage collection

34

Memory Architecture
MP EP

stack frame stack frame

function value static link dynamic link previous EP return address parameters locals operand stack

NP

function value static link dynamic link previous EP return address parameters

MP
mark stack

heap constant area

locals operand stack

SP EP

MP : beginning of the stack frame EP : maximum extent of current frame NP : maximum extent of the heap SP : current top of the operand stack 35

P-code
Basis for later HLL VMs V-ISA
Stack ISA with minimum registers is easily portable to any ISA Stack ISA leads to small binaries Cell-based memory model whose details are not part of ISA Interface to OS is through libraries only
Minimum libraries common to all platforms lead to weak I/O

Difference to modern HLL VM

Support for OO programming Support for networked computing

36

Transformation done by VM
Machine Independent Program File Virtual Machine Implementation Loader Metadata Interpreter Code Native Code Internal Data Structures

Translator

Transform machine-independent program files to machine-dependent code and data

37

Security and Protection of HLL VM

Allow load/execute programs from untrusted sources
VM implementation is protected from applications Rely on protection sandbox
Access to remote files
Protected by the remote system Trusted libraries and security manager

Access to local files Prevent application from accessing memory and code that is outside the sandbox, even though they are shared with VM
Static checking by a trusted loader Dynamic checks by a trusted emulation engine

38

Robustness : Object-Orientation
Class and objects Inheritance, Methods, Polymorphism Objects can only be accessed via references
Array is also intrinsic form of object in JVM and CLI

39

Garbage Collection
Objects are created and float in memory space Garbage During program execution, many objects are created then abandoned, so become garbage Collection Due to limited memory, we collect garbage To improve robustness, make the VM collect garbage automatically

40

Performance Issues
OO languages are slower than non-OO languages VM-based HLL are even slower than native execution CPU speed increases can reduce performance issues But most VMs employ high-performance techniques
Most emulation techniques can be used Interpretation, dynamic binary translation, static translation

Translation is much simpler than in other VMs

No code discovery problem
Dynamic translation can be done even w/o interpretation Even static translation is possible
41

.NET FRAMEWORK

42

COMMON LANGUAGE RUNTIME

The CLR manages and executes code written in .NET langua ges and is the basis of the .NET architecture, similar to the J ava Virtual Machine (JVM). The CLR activates objects, performs security checks on them , lays them out in memory, executes them, and garbage-colle cts them. The CLR executables or Portable Executable (PE) files, which are .NET assemblies or units of deployment. The CLR is the runtime engine that loads required classes , performs just-in-time compilation on needed methods , enforces security checks, and accomplishes a b unch of other runtime functionalities. The CLR executables are either EXE or DLL files that cons 43 ist mostly of metadata and code.

CLR
Manages running code
Verifies type safety Provides garbage collection, error handling Code access security for semi-trusted code

Provides common type system

Value types integer, float, user defined, etc) Reference types Objects, Interfaces

Provides access to system resources

Native API, COM, etc.

44

.NET Portable Executable (PE) File s

A Windows executable, EX E or DLL must conform to t he PE file format, which is derivative of the Microsoft Common Object File Format (COFF). Any compiler that wants to generate Windows executa bles must obey the PE/COF F specification. A .NET PE file consist of 4 parts as shown in the Figur 45 e

How CLR acts as a Virtual Machine?

46

47

Execution scheme of .NET

48

Common language runtime type system

49

Common Language Specification (CLS)

Compilers targeting the .NET Framework de scribe the types they produce with metadat a for two reasons:
Metadata permits types defined in one language to be usable in another language. This facility e nsures language interoperability in the common language runtime. The execution engine requires metadata to man age objects. Managing objects includes require ments such as memory management.

50

CLR vs. JVM

51

Garbage collection
Object oriented programming environment
Problem
Objects are freely created
Not destroyed explicitly in Java

Bounded memory size

Solution
Garbage collection
Garbage : objects that are no longer accessible

Memory reuse for new objects

52

 Root set
Set of references point to objects held in the global memory heap Garbage
Cannot be reached through a sequence of references beginning with the root set

53

54

 Garbage collector
Essential part of JVM implementation Find inaccessible garbage objects
Beginning with the root set

Collect memory resources of garbage Its overhead must be considered

55

 Mark-and-sweep collectors
Mark stage Start with the root references Mark all reachable objects Sweep stage All unmarked objects are collected Combining garbage into a linked list of free objects Relatively fast Memory fragmentation problem Free objects of varying size are scattered Fixed size chunks can be used
56

 Compacting collectors
Free F

E D
C B A
57

 Compacting collectors (contd)

Mark
Find unreachable objects

Compute the new locations for the live objects Move objects Update all references to point to the new locations
Too much overhead Handle pool
Good for updating on garbage collection
58

59

60

 Copying collectors (contd)

Relatively faster than compacting collectors
Combine the sweep with the mark phase

Higher memory requirements

Because half of the heap space is unused

61

 Generational collectors
Object lifetimes : bimodal distribution
Very short lifetime vs. very long lifetime

Group objects according to their age

Avoid repeated copying of the long-lived objects Heap is divided into sub-heaps
Newly created objects are in the nursery heap Garbage-collected frequently Object which survives a certain number of collections in the nursery heap is moved to the tenured heap

62

 Incremental and concurrent collectors

Time consuming problem
Program may pause for long time Serious for real-time application

Solution
Incremental collection Concurrent collection
When multiple processors are available

Synchronization is required
Ex) write barriers
63

Summary

64