Download - HLLvm Garbage
-
8/3/2019 HLLvm Garbage
1/64
1
High-Level LanguageVirtual Machine Architecture
-
8/3/2019 HLLvm Garbage
2/64
2
Contents
Introduction of HLL VM
The Pascal P-code VM
Object-Oriented HLL VM Java VM Architecture
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
6/64
Usual programming language
implementation
6
-
8/3/2019 HLLvm Garbage
7/64
Another programming language
implementation
7
-
8/3/2019 HLLvm Garbage
8/64
And another implementation
8
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
11/64
JVM
Major components
Class loader subsystem
Memory system
Including garbage-collected heap
Emulation engine
11
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
13/64
13
Data accessing
-
8/3/2019 HLLvm Garbage
14/64
Data movement: through stack onl
y
14
-
8/3/2019 HLLvm Garbage
15/64
Run-Time Data Areas
15
-
8/3/2019 HLLvm Garbage
16/64
16
Runtime Data Area
Method area, heap, stack, PC registers
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
19/64
19
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
27/64
Example Contd
27
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
29/64
Data types
29
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
42/64
.NET FRAMEWORK
42
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
46/64
How CLR acts as a Virtual Machine?
46
-
8/3/2019 HLLvm Garbage
47/64
47
-
8/3/2019 HLLvm Garbage
48/64
Execution scheme of .NET
48
-
8/3/2019 HLLvm Garbage
49/64
Common language runtime type
system
49
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
51/64
CLR vs. JVM
51
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
54/64
54
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
57/64
Compacting collectors
57
A
B
C
D
E
F
Free
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
59/64
59
-
8/3/2019 HLLvm Garbage
60/64
60
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
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
-
8/3/2019 HLLvm Garbage
64/64
Summary