High Level Language VMs

High Level Language VMs
This material is based on the book, Virtual Machines: Versatile Platforms for Systems and Processes, Copyright 2005 by Elsevier Inc. All rights reserved. It has been used and/or modified with permission from Elsevier Inc.

VM Interpreter/Translator
HLL VMs Goal: complete platform independence for applications Similar to Process VMs Major difference is specification level: Virtual instruction set + libraries Instead of ISA and OS interface HLL Program HLL Program Compiler front-end Compiler Intermediate Code Portable Code ( Virtual ISA ) Compiler back-end Figs1/hllvm VM loader Object Code ( ISA ) Virt. Mem. Image Loader VM Interpreter/Translator Memory Image Host Instructions Traditional HLL VM HLL VMs

UCSD P-Code Popularized HLL VMs
Provided highly portable version of Pascal Consists of Primitive libraries Machine-independent object file format A set of byte-oriented “pseudo-codes” Virtual machine definition of pseudo-code semantics HLL VMs

UCSD P-Code, contd. Instruction set Stack oriented
MP function value Instruction set Stack oriented Stack “Frame” is part of VM definition static link stack frame MP dynamic link mark stack stack frame previous EP EP return address parameters locals SP operand stack NP EP heap constant area lodi // load variable from current frame (nest 0 depth), // offset 3 from top of mark stack. ldci // push constant 1 addi // add stri // store variable back to location 3 of current frame HLL VMs

UCSD P-Code, contd. Protection via trusted interpreter Advantages
Porting is simplified Don’t have to develop compilers for all platforms VM implementation is smaller/simpler than a compiler VM provides concise definition of semantics Through interpretation, startup time is reduced Generic I/O and Memory interface Tended to be least common denominator  Relatively weak I/O capabilities HLL VMs

Modern HLL VMs Superficially similar to P-code scheme
Stack-oriented ISA Standard libraries BUT, Objective is application portability, not compiler portability Network Computing Environment Untrusted software (this is the internet, after all) Robustness (generally a good idea)  object-oriented programming Bandwidth is a consideration Good performance must be maintained Two major examples Java VM Microsoft Common Language Infrastructure (CLI) HLL VMs

Terminology Java Virtual Machine Architecture  CLI
Analogous to an ISA Java Virtual Machine Implementation CLR Analogous to a computer implementation Java bytecodes  Microsoft Intermediate Language (MSIL), CIL, IL The instruction part of the ISA Java Platform  .NET framework ISA + Libraries; a higher level ABI HLL VMs

Modern HLL VMs Compiler forms program files (e.g. class files)
Standard format In theory any compiler can be used Program files contain both code and metadata Metadata Code Machine Independent Program File Loader Virtual Machine Implementation Interpreter Internal Data Structures Translator Native Code HLL VMs

Robustness: Object-Orientation
Objects Data carrying entities Dynamically allocated Must be accessed via pointers or references Methods Procedures that operate on objects Method operating on an object is like “sending a message” Class A type of object and its associated methods Object created at runtime is an instance of the class Data associated with a class may be dynamic or static HLL VMs

Security A key aspect of modern network-oriented VMs
Public File Remote System Other File Local System Accessible Local File application VMM Other Network User Process Sandbox Boundary A key aspect of modern network-oriented VMs Rely on “protection sandbox” Must protect: Remote resources (files) Local files Runtime from user process This is the first generation security method – still the default HLL VMs

Protection Sandbox Remote resources Local resources VM software
class file class file class file class file Remote resources Protected by remote system Local resources Protected by security manager VM software Protected via static/dynamic checking Network, File System loaded loaded loaded method method method loaded method lib. method lib. method loaded method native method loaded local method Figs11/big file native method local standard file libraries trusted security Emulation Engine loader agent trusted trusted trusted HLL VMs

Java 2 Security: Signing
Binary Class hash encrypt Transmit Signed Hash decrypt private key public key compare match => signature OK Figs11/big HLL VMs

Java 2 Security: Stack Walking
Method 1 Method 2 Method 3 Method 4 System Untrusted principal Full Write A only Write B permissions Method 5 (in io API) Check Method Inspect Stack operation prohibited X Figs11/big HLL VMs

Garbage Collected Heap
Objects are created and “float” in memory space Tethered by references In architecture, memory is unbounded in size In reality it is limited Garbage creation During program execution, many objects are created then abandoned (become garbage) Collection Due to limited memory space, Garbage should be collected so memory can be re-used Forcing programmer to explicitly free objects places more burden on programmer Can lead to memory leaks, reducing robustness To improve robustness, have VM collect garbage automatically HLL VMs

Network Friendliness Support dynamic class file loading on demand
Load only classes that are needed Spread loading out over time Compact instruction encoding Use stack-oriented ISA (as in Pascal) Metadata also consumes bandwidth, however Overall, it is probably a wash HLL VMs

Java “ISA” Includes Formalized in class file specification
Bytecode (instruction) definitions Metadata: data definitions and inter-relationships Formalized in class file specification HLL VMs

Java Architected State
Implied Registers PC Stack Pointer etc. Stack Locals Operands Heap Objects Arrays (intrinsic objects) Class file contents Constant pool holds immediates and other constant information HLL VMs

Implied Registers Program Counter Local variable pointer
Operand stack pointer Current frame pointer Constant pool base HLL VMs

Stack Arguments Locals Operands Accessed as locals
Same number and types of data independent of control flow path HLL VMs

Heap Objects are created on heap Each application has only one
Each application has its own JVM instructions allocate objects on heap No instruction to release memory Garbage collection is part of implementation Object representation is implementation dependent HLL VMs

Data items Types are defined, but not implementation details
Reference types (pointers) Primitive types, e.g. byte, short, long Exact sizes are not given Only the range of values that can be held e.g. byte is between –128 and +127 Data can only be located via references; as fields of objects in heap offsets using constant pool pointer, stack pointer HLL VMs

Data Accessing HLL VMs HEAP CONSTANT POOL STACK FRAME Locals Array
index Object Instruction stream index opcode operand operand opcode opcode operand index opcode operand operand STACK FRAME opcode opcode operand opcode Locals opcode operand implied implied Operands Object Object HLL VMs

Instruction Set Defined for class file, not memory image Bytecodes
One byte opcode Zero or more operands Opcode indicates how many Can take operands from Instruction Current constant pool Current frame local variables Values on operand stack Distinguish storage types and computation types opcode opcode index opcode index1 index2 opcode data opcode data1 data2 HLL VMs

Instruction Types Pushing constants onto the stack
Moving local variable contents to and from the stack Managing arrays Generic stack instructions (dup, swap, pop & nop) Arithmetic and logical instructions Conversion instructions Control transfer and function return Manipulating object fields Method invocation Miscellaneous operations Monitors HLL VMs

Data Movement All data movement takes place through stack GLOBAL
CONSTANT STORAGE POOL STACK FRAME Instruction stream locals opcode operand operand opcode opcode operand operand stack ALU HLL VMs

Bytecode Example public int perimeter(); PC instruction 0: iconst_2
1: aload_0 2: getfield #2; //Field: sides reference 5: iconst_0 6: iaload 7: aload_0 8: getfield #2; //Field: sides reference 11: iconst_1 12: iaload 13: iadd 14: imul 15: ireturn HLL VMs

Stack Tracking Operand stack at any point in program have:
Same number of operands Of same types In same order Regardless of control flow path getting there Helps with static type checking HLL VMs

Stack Tracking, example
Valid Sequence iload A //push int. A from local mem. iload B //push int. B from local mem. If_cmpne 0 else // branch if B ne 0 iload C // push int. C from local mem. goto endelse else iload F //push F endelse add // add from stack; result to stack istore D // pop sum to D HLL VMs

Stack Tracking, example
Invalid Sequence Stack at skip 1 depends on path iload B // push int. B from local mem. If_cmpne 0 skip1 // branch if B ne 0 iload C // push int. C from local mem. skip1 iload D // push D iload E // push E if_cmpne 0 skip2 // branch if E ne 0 add // add stack; result to stack skip2 istore F // pop to F HLL VMs

Invokevirtual invokevirtual, indexbyte1, indexbyte2
Stack before: …., objectref, arg1, arg2,.. Stack after: …. Also invokeinterface, invokestatic, invokespecial HLL VMs

Invokevirtual (in brief)
Form 16-bit index by concatenating index bytes Look up indexed constant pool entry Entry must be CONSTANT_Methodref_info entry Resolve entry To get method table index and Number of words of parameters nargs Check arguments Operand stack must contain nargs-1 words of parameters and objectref (reference to object method is invoked on) Param words must match order and type required by method Create new stack frame Place objectref word and parameter words into local variables of frame Set PC to first instruction in new method HLL VMs

Exception Table Exceptions identified by table in class file
Address Range where checking is in effect Target if exception is thrown Operand stack is emptied If no table entry in current method Pop stack frame and check calling method Default handlers at main From To Target Type Arithmetic Exception HLL VMs

Binary Classes Formal ISA Specification Magic number and header
Version Information Constant Pool Const. Pool Size Access Flags This Class Super Class Interfaces Interface Count Field Information Field count Methods count Methods Attributes Count Attributes Binary Classes Formal ISA Specification Magic number and header Major regions preceded by counts Constant pool Interfaces Field information Methods Attributes HLL VMs

Java Virtual Machine An abstract entity that gives meaning to class files Has many concrete implementations Hardware Interpreter JIT compiler Persistence An instance is created when an application starts Terminates when the application finishes HLL VMs

Structure of Virtual Machine
Class Loader class files Subsystem Memory Garbage native method Java Collector heap method area stacks stacks Figs11/vmstruct data & addresses instructions PCs native & Execution Engine method implied native method interface regs libraries HLL VMs

Stacks Both java and native stacks Java stack has architected format
Native stack is implementation dependent stack frame Java Stacks Native method stacks thread 1 thread 2 thread 3 Figs11/stacks HLL VMs

Structure of Virtual Machine, contd.
Method Area Type information provided by class loader Heap Area Contains objects created by program PC Register & Implied Registers Every created thread gets a set Java stacks Every created thread gets one Divided into Frames Contains state of method invocations for the thread Local variables, parameters, return value, operand stack Native method stacks Special area for implementation-dependent native methods HLL VMs

Method Area Holds loaded types
Exact format, etc. is implementation dependent E.g. may be little or big endian BUT data in classfile is big endian by definition Type information includes Name Interface info Constant pool (referenced by index) Field information Method information (including bytecodes) Static variables Reference to class Classloader Reference to class Class Etc. HLL VMs

Class Loader Subsystem
Primordial loader Other loaders that are part of apps Tasks: Finds and imports binary information describing type Verifies correctness of type Allocates and initializes memory for class variables Resolves symbolic references to direct references Invokes initialization code HLL VMs

Protection Sandbox HLL VMs Global Memory Objects with statically
defined(fixed) types Local Storage Operand Storage Declared (fixed) Tracked Load: type determined from reference/field type Store: must be to reference and field with correct types Move to local storage: must be to a location with correct type Move to operand stroage: type determined from local storage type ALU tracked types Array loads are range checked Array stores are HLL VMs

Protection Sandbox: Security Manager
A trusted class containing check methods Attached when Java program starts Cannot be removed or changed User specifies checks to be made Files, types of access, etc. Operation Native methods that involve resource accesses (e.g. I/O) first call check method(s) HLL VMs

Garbage Collection Garbage: objects that are no longer accessible
Examples: D, G, H Global Heap A B Root Set C D . . . E F G H HLL VMs

Garbage Collection A large topic on its own Mark and sweep
Start with root set of references On stack, static objects, constant pool Trace and mark all reachable objects Sweep through heap, collecting marked objects Keep free space in linked list Advantage: Fast Does not require moving object/pointers Disadvantage: Discontiguous free space, fragmentation Use range of fixed object sizes (pwrs of 2) with a free list for each Allocate new objects from best-fit free list HLL VMs

Compacting Collector Make free space contiguous
Involves multiple passes through heap A lot of object movement => many pointer updates free A free B C D A B E C F E G G H HLL VMs

Simplifying Pointer Updates
Add a level of indirection Handle pool When an object is moved only handle pointer must be updated Classic solution But makes every object access slow Global Heap Handle Pool Object Pool object references (e.g. on stack) A B HLL VMs

Copying Collector Divide heap into halves Collect when one half full
free Divide heap into halves Collect when one half full Copy into unused half during sweep phase Reduces passes through heap “Wastes” half of heap A unused B C E G free A B C D unused E F G H HLL VMs

Generational Collector
Divide heap into halves “tenured” and “nursery” Collect nursery more frequently Move long-lived objects into tenured half Objects have either very long or very short lives HLL VMs

Concurrent Collection
Long pauses for collection avoided Parallelism if multiple threads available Problem: if pointer from marked object is changed One solution: write barriers – check pointer updates A B A B Root Set Root Set . . . . . C D . C D HLL VMs

Garbage Collection Summary
Collector Collection Time Object Allocation Access Memory Efficiency Comments Mark and Sweep good poor medium Allocation requires search for proper sized free memory block (multi-sizes) Multi-sizes helps allocation time more than it benefits memory efficiency Compacting Collection requires multiple passes Copying (with handles) Memory efficiency poor due to unused space. (without handles) Pointers must be updated for all moved objects HLL VMs

Verification Class files are checked when loaded Internal Checks
To ensure security and protection Internal Checks Checks for magic number Checks for truncation or extra bytes Each component specifies a length Make sure components are well-formed Bytecode checks Check valid opcodes Perform full path analysis Regardless of path to an instruction contents of operand stack must have same number and types of items Checks arguments of each bytecode Check no local variables are accessed before assigned Makes sure fields are assigned values of proper type HLL VMs

Java Native Interface (JNI)
Allows Java and native SW to interoperate E.g. Java can call C program (and vice versa) Native routines allow access of Java data Java Side Native Side Java HLL Program C Program Compile Compile and and Load Load invoke native method Bytecode Native Machine Code Methods load/store getfield/ JNI putfield get/put Native Data Structures object object array HLL VMs

JVM Bytecode Emulation
Interpretation Simple, fast startup, but slow Just-In-Time (JIT) Compilation Compile each method when first touched Simple, static optimizations Hot-Spot Compilation Find frequently executed code Apply more aggressive optimizations on that code Typically phased with interpretation or JIT Dynamic Compilation Based on Hot-Spot compilation Use runtime information to optimize More later… HLL VMs

Microsoft CLI Common Language Infrastructure Part of .NET framework
Allows multiple HLLs and multiple Platforms Allows both verifiable and unverifiable modules (class files) Verifiability is different from validity Unverifiable modules must be trusted by user Verifiable and unverifiable modules can be mixed (but the program becomes unverifiable) HLL VMs

Microsoft CLI Interoperability
C# program Java Program Visual Basic.Net Managed C++ program Compile Compile Compile Compile Verifiable Verifiable Verifiable Unverifiable Module Module Module Module Common Common Language Runtime Language Runtime X86 Platform IA-64 Platform HLL VMs

Microsoft CLI and MSIL Similar to Java and JVM Some differences
Object oriented Stack-based ISA Some differences Much broader in scope ISA not meant for interpretation Module can be valid (but not verifiable), verifiable, or invalid HLL VMs

MSIL Memory Architecture
Locals and Arguments not part of stack Metadata streams hold constant information opcode operand Instruction stream Metadata Streams evaluation stack Local Variables GLOBAL STORAGE ALU . . . Argument Table HLL VMs

Comparison: MSIL & Java bytecodes
Similar for most memory/ALU instructions “Generic” arithmetic instructions in MSIL Better suited for JIT than interpretation 0: iconst_2 1: aload_0 2: getfield #2 5: iconst_0 6: iaload 7: aload_0 8: getfield #2 11: iconst_1 12: iaload 13: iadd 14: imul 15: ireturn 0: ldc.i4.2 1: ldarg.0 2: ldobj <token> 5: ldc.i4.0 6: ldelem.i4 7: ldarg.0 8: ldobj <token> 11: ldc.i4.1 12: ldelem.i4 13: add 14: mul 15: ret java MSIL HLL VMs

Unmanaged Memory Unmanaged pointers are 32-bit native integers
Unmanaged pointers can be manipulated freely Like C pointers Instructions that operate on blocks of memory Allocate Copy Initialize Indirect Call instruction with unmanaged pointer HLL VMs

High Performance Optimization
Staged Optimization Philosophy (again) Faster program startup Compilation spread over time Less noticeable to user Compiling only hot code allows optimization time to be used where needed Consumes less memory for compiled code Waiting longer before optimizing gives better profile information HLL VMs

Staged Optimization Framework
Simple Optimizing Control Compiler Compiler Bytecodes Interpreter Profile Data Compiled Code Optmized Code Host Platform HLL VMs

Optimizations Code Re-layout Method Inlining
Code “straightening” as in binary optimization (earlier) Method Inlining Small methods calling sequence shorter than method code should always be inlined. Larger methods apply cost-benefit analysis benefit based on profile data HLL VMs

Call Graph Profiling Guides method inlining
Call graph – similar to control flow graph Stack frame profile – localized view of CFG MAIN A B X Y C 900 1500 100 25 1000 HLL VMs

Virtual Function Calls
The target of an invokevirtual can change dynamically due to polymorphism would seem to inhibit method inlining Often the target does not change use guarded inlining invokevirtual area If (target reference == circle) then inlined code for area of a circle . Else invokevirtual area HLL VMs

Polymorphic Inline Caching
For use if call is truly polymorphic Avoids costly method table look-up circle area code if type = circle jump to circle area code square area code . . . . . . else if type = square invokevirtual area call PIC stub jump to square area code . . . . . . else call lookup update PIC stub; Polymorphic Inline Cache stub method table lookup code HLL VMs

Multiversioning and Specialization
Use separate code versions for common case(s) Specialize common case(s) Possibly based on data profiles for (int i = 0; i < 1000; i++) { if (A[i] < 0) B[i] = -A[i]*C[i]; else B[i] = A[i]*C[i]; } if (A[i] == 0) B[i]= 0; HLL VMs

Deferred Compilation Defer compilation of uncommon case until needed
for (int i = 0; i < 1000; i++) { if (A[i] < 0) B[i] = -A[i]*C[i]; else B[i] = A[i]*C[i]; } if (A[i] == 0) B[i]= 0; Jump to dynamic compiler for deferred compilation HLL VMs

On Stack Replacement Optimization (or de-optimization) of currently running method may require changes to stack frame Program dominated by very long-running single loop -- can’t wait for next method call Deferred compilation requires immediate replacement Debugging may require de-optimization HLL VMs

On Stack Replacement, contd.
Steps optimize/de-optimize method code method method code stack code stack opt. level y opt. level x implementation architected Implementation frame x frame frame y generate new extract architected state stack frame HLL VMs

On Stack Replacement, contd.
Example: method inlining For optimization or de-optimization stack stack Method A Architected frame frame A Method B Architected Method A,B,C frame frame B inlined frame Method C Architected frame frame C HLL VMs

Scalar Replacement Replace object field with scalar
Requires “escape analysis” No other references outside optimization region class A { int x; int y; void foo() { } int t1 = 1; void foo() { int t2 = t1 + 2; A a = new A(); System.out.println(t2); a.x = 1; } a.y = a.x + 2; System.out.println(a.y); } HLL VMs

Low Level Optimizations
Many optimizations similar to conventional binary optmizations CSE, dead code removal, copy & constant propagation etc. Some are extended to null checks and array range checks Example: hoist array range check for (int i = 0; i < j; i++) { sum += A[i]; <range check A> } If (j < A.length) then for (int i = 0; i < j; i++) { else for (int i = 0; i < j; i++) { HLL VMs

Low Level Optimizations
Example: redundant null check removal Null check itself isn’t costly Use out-of-range address for null Trap will happen automatically Relaxes precise state constraint p := new Z q := new Z r := p . . . p.x := … <null check p> … := p.x q.x := … <null check q> r.x := ... <null check r (p)> HLL VMs

Optimizing Garbage Collection
Remove level of indirection due to handles Works well with generational collectors (fewer copies) Used in Sun HotSpot object references handle pool object pool ptr into handle pool ptr into object pool instance data ptr into handle pool Figs11/obref heap ptr into heap instance data ptr into heap HLL VMs

IBM Jikes (Jalapeno) JVM
Dynamic Compiler developed at IBM Research Uses Compile-Only strategy Baseline compiler Straight translation to native code Simulates operand stack; no register allocation Optimizing compiler Translates to intermediate representation Performs simple register allocation Three levels of optimization Compiler Bytecode Bytes /Millisecond Baseline 274.14 Opt. Level 0 8.77 Opt. Level 1 3.59 Opt. Level 2 2.07 HLL VMs

Thread Scheduling Jikes multiplexes Java threads onto JVM virtual processors Compiler generates yield points in each thread Loop back edges & method prologues Test control bit at yield points If set, yield virtual processor Bit set by timer interrupt mechanism Optimization threads run concurrent with execution threads HLL VMs

Big Picture HLL VMs Collected sample New code Executing Code Runtime
Re-compilation Measurement Subsystem Subsystem Instrumentation/ Compilation Plan Method AOS Database Compilation Optimizing Samples (Profile Data) Thread Compiler Instrumented/ Optimized Code Hot Method Organizer Controller Event queue Compilation queue HLL VMs

Runtime Measurement Subsystem
Gathers raw performance data via software instrumentation or hardware performance counters Sampling done at thread switch time Current method at time of switch is sampled If method prologue, both caller and callee are recorded Summarizes information via organizer threads Passes summary to the controller or AOS database HLL VMs

Controller Coordinates activities of runtime measurement system and recompilation system Can instruct measurement system to continue or change profiling strategy Can direct recompilation system to insert/remove profile code Constructs compilation plans using profile data Uses analytical cost-benefit model Sends plan to recompilation subsystem HLL VMs

Recompilation Subsystem
Contains compilation threads Takes place concurrent with execution Uses optimization plan generated by controller Which optimizations Profile info for feedback-directed optimizations Instrumentation to be inserted HLL VMs

Sampling Three organizer threads handle raw data
Method listener – simply collects data Hot method organizer Awakened after a specified number of samples Finds hot methods If threshold exceeded Not already fully optimized Enqueue event in queue to controller Decay organizer Periodically decays method counters Gives more weight to recent samples Controller adjusts threshold balances # hot methods with allowable overhead HLL VMs

When to Recompile? Analytical Model
For method m currently compiled at level I Ti – expected execution time in m if not recompiled Cj – the cost of recompiling m at level j > I Tj – expected execution time in m after recompilation Controller determines optimal level j Minimize Cj + Tj If Cj +Tj < Ti, then recompile at level j Major problem: estimating future cost and benefit Currently assumes future time == past execution time Speedup estimates determined offline using benchmarks? Sk speedup at level k versus level 0 Tj = Ti * Si/Sj Recompilation cost Linear function of method size HLL VMs

Feedback-Directed Inlining
Build dynamic call graph using samples Identify hot edges via sample mechanism Edge listener walks call graph to find hot edges Samples passed to dynamic call graph organizer Dynamic call graph organizer periodically invokes adaptive inline organizer Adaptive inline organizer Identifies candidate methods By considering edges that exceed hotness threshold Controller estimates boost factor and applies cost/benefit model HLL VMs

Compilers studied Baseline as a JIT Level 0 optimization as a JIT
Adaptive multi-level Method oriented Adaptive + Feedback Directed Optimization Code region oriented; more focused HLL VMs

Startup/Steady State Startup Steady State Small data set Run once
Data set order of magnitude larger than startup Run five iterations; take performance of best iteration No startup overhead HLL VMs

Results: Adaptive Compilation
For startup, adaptive shows big gain; JIT does not Level 0 is best JIT For many methods, better to stick with baseline AOS and AOS+feedback give 1.75 speedup Optimize only methods where there is some benefit In Steady State, JIT 0 gets a lot of the gain Some improvement with JIT 1 and JIT 2 JITs optimize on first iteration and get out of the way AOS + FDO additional significant improvement for some benchmarks More focused optimizations work better in some cases HLL VMs

Startup Performance HLL VMs

Steady State Performance
HLL VMs

Results: Overhead HLL VMs Inlining Organizer Decay Organizer
1% Opt. Recompilation 0% 7% Method Organizer 0% Controller 0% Garbage Collection 6% Application Threads 86% HLL VMs

Summary: HLL VMs vs. Process VMs
Memory architecture Object model is less implementation-dependent No compatibility problems due to size limitations/differences Memory protection Pointers very carefully controlled No rogue load/stores Precise Exceptions Exception checking is explicit (no masks) Operand stack imprecise within a method Locals imprecise if exception goes to higher level HLL VMs

Summary: HLL VMs vs. Process VMs
Instruction set dependences No registers No condition codes Code discovery Restricted, explicit control flow All code can be discovered at method entry Self Modify-Referencing Code Simply doesn’t exist HLL VMs

High Level Language VMs

Similar presentations

Presentation on theme: "High Level Language VMs"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

High Level Language VMs

Similar presentations

Presentation on theme: "High Level Language VMs"— Presentation transcript:

Similar presentations

About project

Feedback