hllvm garbage

8/3/2019 HLLvm Garbage

1/64

1

High-Level LanguageVirtual Machine Architecture


2/64

2

Contents

Introduction of HLL VM

The Pascal P-code VM

Object-Oriented HLL VM Java VM Architecture


3/64

3

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.

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

Hardware

Library of HLL

OS

HLL Program


4/64

4

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 architecturethan instruction set architecture


5/64

5

HLL VMs from Language Perspectives

HLL program

Intermediate code

Object code(Real ISA)

Memory image

Compiler frontend

Compiler backend

LoaderVM interpreter or translator

HLL program

Portable code(Virtual ISA)

Virtual memoryimage

Host instruction

Compiler frontend

VM loader

distributed


6/64

Usual programming language

implementation

6


7/64

Another programming language

implementation

7


8/64

And another implementation

8


9/64

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 interpreter3. 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.

9


10/64

Examples:Language IR Implementation(s)

10

Language IR ImplementationJava JVM bytecode Interpreter, JIT

C# MSIL JIT

Pascal p- code

--

Interpreted

compiled

C, C++ -- compiled


11/64

JVM

Major components

Class loader subsystem

Memory system

Including garbage-collected heap

Emulation engine

11


12/64

12

Java VM Architecture

Java VM is for executing Java programs

Usually referred to as Java Runtime Environment (JRE)

Contains the Java virtual machine, classes comprisingthe Java 2 Platform API, and supporting files

JDK (Java development kit): JRE, Development Tools(compiler, debugger), additional library

a.java b.java c.java

a.class b.class c.class

a.class b.class c.class

Object.class String.class

Javacompiler JVM


13/64

13

Data accessing


14/64

Data movement: through stack onl

y

14


15/64

Run-Time Data Areas

15


16/64

16

Runtime Data Area

Method area, heap, stack, PC registers


17/64

Memory regions

Each time a class is loaded, info about the class is copied into t

hemethod area.

While a program is running, all instantiated objects (instances

of classes, arrays) are allocated on theheap. When a new thread comes into existence, it gets its ownJava

stack and its ownpc 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 anative

method stack.17


18/64

Dynamic class loading

Class loader subsystem

Convert the class file into an implementation-dependent 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/64

19


20/64

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


21/64

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


22/64

The Heap One entry for each object

Increases with each instance creation

Decreases with garbage collection (mechanism not specified)

Object information: instance field values,pointer to class

Shared by all threads.

22


23/64

Java Stack JVM pushes and pops frames onto this

stack

Each frame corresponds to the invocationof a method

Call a method push its frame onto the

stack

Return from a method pop its frame

Frame holds parameter values, localvariables, intermediate values etc.

23


24/64

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


25/64

Native method interface

To access OS-managed functions

Ex) file I/O, graphics

To bridge the gap between the platform-independent and platform-dependent partsof the overall system

25


26/64

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


27/64

Example Contd

27


28/64

28

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


29/64

Data types

29


30/64

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


31/64

Arithmetic Operations Operands are normally taken from operan

dstack and the result pushed back there

iadd, ladd, fadd, dadd

isub ...

imul ...

idiv ...

31


32/64

32

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


33/64

33

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

Hardware

Library of Pascal

OS

Pascal Program binary

Platform( OS, Hardware, etc)

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

Pascal Program P-code


34/64

34

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


35/64

35

Memory Architecture

stack frame

stack frame

heap

constant area

MP

EP

NP

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

EP

function valuestatic link

dynamic linkprevious EP

return addressparameters

locals

operand stack

MP

SP

mark stack

function value

static linkdynamic linkprevious EP

return addressparameters

locals

operand stack


36/64

36

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


37/64

37

Transformation done by VM

Metadata

Code

Loader

Interpreter

Translator

Internal DataStructures

Native Code

Machine IndependentProgram File

Virtual Machine Implementation

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


38/64

38

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

Access to local files

Trusted libraries and security manager

Prevent application from accessing memory and code that isoutside the sandbox, even though they are shared with VM

Static checking by a trusted loader

Dynamic checks by a trusted emulation engine


39/64

39

Robustness : Object-Orientation

Class and objects

Inheritance, Methods, Polymorphism

Objects can only be accessed via references

Arrayis also intrinsic form of object in JVM and CLI


40/64

40

Garbage Collection

Objects are created and floatin memory space

Garbage

During program execution, many objects arecreated then abandoned, so become garbage

Collection

Due to limited memory, we collect garbage

To improve robustness, make the VM collectgarbage automatically


41/64

41

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


42/64

.NET FRAMEWORK

42


43/64

COMMON LANGUAGE RUNTIME

The CLR manages and executes code written in .NET languages and is the basis of the .NET architecture, similar to the Java Virtual Machine (JVM).

The CLR activates objects, performs security checks on them

,lays them out in memory, executes them, and garbage-collects them.

The CLR executables or Portable Executable (PE) files, whichare .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 bunch of other runtime functionalities.

The CLR executables are either EXE or DLL files that cons

ist mostly of metadata and code.43


44/64

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 P bl E bl (PE) Fil


45/64

.NET Portable Executable (PE) Files

A Windows executable, EXE or DLL must conform to the PE file format, which isderivative of the Microsoft

Common Object File Format(COFF).

Any compiler that wants togenerate Windows executa

bles must obey the PE/COFF specification.

A .NET PE file consist of 4parts as shown in the Figur

e45


46/64

How CLR acts as a Virtual Machine?

46


47/64

47


48/64

Execution scheme of .NET

48


49/64

Common language runtime type

system

49


50/64

Common Language Specification

(CLS)

Compilers targeting the .NET Framework describe the types they produce with metadata for two reasons:

Metadata permits types defined in one languageto be usable in another language. This facility ensures language interoperability in the commonlanguage runtime.

The execution engine requires metadata to man

age objects. Managing objects includes requirements such as memory management.

50


51/64

CLR vs. JVM

51


52/64

Garbage collection

Object oriented programmingenvironment

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


53/64

Root set

Set of references point to objects held inthe global memory heap

Garbage Cannot be reached through a sequence of

references beginning with the root set

53


54/64

54


55/64

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


56/64

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


57/64

Compacting collectors

57

A

B

C

D

E

F

Free


58/64

Compacting collectors (contd)

Mark

Find unreachable objects

Compute the new locations for the liveobjects

Move objects

Update all references to point to the newlocations

Too much overhead

Handle pool

Good for updating on garbage collection58


59/64

59


60/64

60


61/64

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


62/64

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 nurseryheap

Garbage-collected frequently

Object which survives a certain number ofcollections in the nurseryheap is moved to thetenuredheap

-

62


63/64

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 barriers63


64/64

Summary

hllvm garbage

Documents