Smalltalk Implementation Harry Porter, October 2009 Smalltalk Implementation: Optimization Techniques Prof. Harry Porter Portland State University 1.

Slides:



Advertisements
Similar presentations
Memory.
Advertisements

Memory Protection: Kernel and User Address Spaces  Background  Address binding  How memory protection is achieved.
CS 333 Introduction to Operating Systems Class 12 - Virtual Memory (2) Jonathan Walpole Computer Science Portland State University.
3/17/2008Prof. Hilfinger CS 164 Lecture 231 Run-time organization Lecture 23.
Multiprocessing Memory Management
Chapter 3.2 : Virtual Memory
JVM-1 Introduction to Java Virtual Machine. JVM-2 Outline Java Language, Java Virtual Machine and Java Platform Organization of Java Virtual Machine Garbage.
Main Memory. Background Program must be brought (from disk) into memory and placed within a process for it to be run Main memory and registers are only.
CS 333 Introduction to Operating Systems Class 12 - Virtual Memory (2) Jonathan Walpole Computer Science Portland State University.
COP4020 Programming Languages
CSc 453 Interpreters & Interpretation Saumya Debray The University of Arizona Tucson.
Basics of Operating Systems March 4, 2001 Adapted from Operating Systems Lecture Notes, Copyright 1997 Martin C. Rinard.
1 Chapter 3.2 : Virtual Memory What is virtual memory? What is virtual memory? Virtual memory management schemes Virtual memory management schemes Paging.
Background Program must be brought into memory and placed within a process for it to be run. Input queue – collection of processes on the disk that are.
By Teacher Asma Aleisa Year 1433 H.   Goals of memory management  To provide a convenient abstraction for programming  To allocate scarce memory resources.
COP4020 Programming Languages Subroutines and Parameter Passing Prof. Xin Yuan.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Memory: Relocation.
Virtual Machines, Interpretation Techniques, and Just-In-Time Compilers Kostis Sagonas
By Teacher Asma Aleisa Year 1433 H.   Goals of memory management  To provide a convenient abstraction for programming.  To allocate scarce memory.
Main Memory. Chapter 8: Memory Management Background Swapping Contiguous Memory Allocation Paging Structure of the Page Table Segmentation Example: The.
LECTURE 19 Subroutines and Parameter Passing. ABSTRACTION Recall: Abstraction is the process by which we can hide larger or more complex code fragments.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 8: Main Memory.
Main Memory CSSE 332 Operating Systems Rose-Hulman Institute of Technology.
Sung-Dong Kim, Dept. of Computer Engineering, Hansung University Java - Introduction.
Smalltalk Implementation
Non Contiguous Memory Allocation
Instruction Set Architectures
CE 454 Computer Architecture
Interpreted languages Jakub Yaghob
Memory Caches & TLB Virtual Memory
Chapter 8: Main Memory.
Run-time organization
“Efficient Implementation of the Smalltalk-80 System”
CS510 Operating System Foundations
Design III Chapter 13 9/20/2018 Crowley OS Chap. 13.
Paging and Segmentation
Chapter 8: Main Memory.
Memory Management Lectures notes from the text supplement by Siberschatz and Galvin Modified by B.Ramamurthy 11/12/2018.
Operating System Concepts
Memory Management 11/17/2018 A. Berrached:CS4315:UHD.
Memory Management Lectures notes from the text supplement by Siberschatz and Galvin Modified by B.Ramamurthy Chapter 8 11/24/2018.
Background Program must be brought into memory and placed within a process for it to be run. Input queue – collection of processes on the disk that are.
CSc 453 Interpreters & Interpretation
Lesson Objectives Aims Key Words Compiler, interpreter, assembler
Memory Management Lectures notes from the text supplement by Siberschatz and Galvin Modified by B.Ramamurthy Chapter 9 12/1/2018.
Lecture 29: Virtual Memory-Address Translation
Lecture 3: Main Memory.
Translation Buffers (TLB’s)
Memory Management Lectures notes from the text supplement by Siberschatz and Galvin Modified by B.Ramamurthy Chapter 9 4/5/2019.
Translation Buffers (TLB’s)
Introduction to Virtual Machines
Evolution in memory management techniques
Introduction to Virtual Machines
CS703 - Advanced Operating Systems
Evolution in memory management techniques
Evolution in memory management techniques
Lecture 4: Instruction Set Design/Pipelining
Translation Buffers (TLBs)
Mechanism: Address Translation
COMP755 Advanced Operating Systems
Chapter 8: Main Memory.
OPERATING SYSTEMS MEMORY MANAGEMENT BY DR.V.R.ELANGOVAN.
CSc 453 Interpreters & Interpretation
Student : Yan Wang student ID:
Review What are the advantages/disadvantages of pages versus segments?
Dynamic Binary Translators and Instrumenters
CSE 542: Operating Systems
Page Main Memory.
Presentation transcript:

Smalltalk Implementation Harry Porter, October 2009 Smalltalk Implementation: Optimization Techniques Prof. Harry Porter Portland State University 1

Smalltalk Implementation Harry Porter, October 2009 Optimization Ideas Just-In-Time (JIT) compiling When a method is first invoked, compile it into native code. Caching the Method Dictionary Method Look-up will be speeded up. Inline Method Sending Will turn many SENDs into native CALL instructions Use the hardware calling stack MethodContexts  activation records allocated on a stack Code the VM directly in Smalltalk Automatic translation into “C” 2

Smalltalk Implementation Harry Porter, October 2009 Misc Points Porting the Smalltalk Interpreter The virtual machine is implemented in Smalltalk! Using a subset of Smalltalk, called “Slang” The image also includes a translator / compiler Slang  “C” Steps to porting: Produce automatically generated interpreter in “C” Hand-code the machine-dependent parts in “C” Compile Use any existing image 3

Smalltalk Implementation Harry Porter, October 2009 Misc Points Porting Images Each VM executes the same bytecodes. Any image can be executed on by any VM. EXAMPLE: An image produced on MAC OS X can be executed on Windows. Porting Code Fragments 4

Smalltalk Implementation Harry Porter, October 2009 Misc Points Porting Images Each VM executes the same bytecodes. Any image can be executed on by any VM. EXAMPLE: An image produced on MAC OS X can be executed on Windows. Porting Code Fragments Also, code fragments can be filed out … and filed in to another image Will it work? The Smalltalk language is uniform. What pre-existing classes does the code use? 5

Smalltalk Implementation Harry Porter, October 2009 Misc Points Hash Values Some classes rely on “hash values”. Dictionary, Set, etc. Every object must be capable of providing its hash value: i := x hashValue. 6

Smalltalk Implementation Harry Porter, October 2009 Misc Points Hash Values Some classes rely on “hash values”. Dictionary, Set, etc. Every object must be capable of providing its hash value: i := x hashValue. Two objects can contain exactly the same values. They differ only in where they are in memory …and GC will move objects around 7

Smalltalk Implementation Harry Porter, October 2009 Misc Points Hash Values Some classes rely on “hash values”. Dictionary, Set, etc. Every object must be capable of providing its hash value: i := x hashValue. Two objects can contain exactly the same values. They differ only in where they are in memory …and GC will move objects around Need special VM support for hash values! Each object contains a hash value. 12 bits Stored in it header Initialized when the object is created 8

Smalltalk Implementation Harry Porter, October Optimizations to the Interpreter Virtual Machine Does not match underlying hardware well Examples: OOP/SmallInteger Tagging Registers versus Stacks in Context objects Bytecodes vs. Machine Instructions The bytecodes are interpreted Fetch-decode-execute done at two levels. Difficult to optimize bytecodes Bytecodes are complex operations Corresponding to several machine level instructions

Smalltalk Implementation Harry Porter, October “Just in Time” Compiling Translate bytecodes into native machine language … and execute them directly Do it “on the fly” … on individual methods Source  bytecodes  machine instructions When the method is first invoked… Call the JIT compiler Translate bytecodes to native instructions Save the native code for next time.

Smalltalk Implementation Harry Porter, October “Just in Time” Compiling Benefits: Optional Compatible with existing system Still have bytecodes (for the debugging tools) Can perform many optimizations at the native code level Can do it just to frequently invoked methods Running out of memory? Throw away some of the compiled methods

Smalltalk Implementation Harry Porter, October “Just in Time” Compiling Problem: Activation records are user-visible MethodContexts, BlockContexts Activation record contains a pointer to the current bytecode “instructionPointer” = “Program Counter (PC)” Used by the debugging tools! Solution:

Smalltalk Implementation Harry Porter, October “Just in Time” Compiling Problem: Activation records are user-visible MethodContexts, BlockContexts Activation record contains a pointer to the current bytecode “instructionPointer” = “Program Counter (PC)” Used by the debugging tools! Solution: Whenever an activation record becomes user-visible… Map the native code PC back into a bytecode PC

Smalltalk Implementation Harry Porter, October Allocating Contexts on the Hardware Stack The hardware supports stacks & procedure CALLs well. “stack frame” = “activation record”

Smalltalk Implementation Harry Porter, October Allocating Contexts on the Hardware Stack The hardware supports stacks & procedure CALLs well. “stack frame” = “activation record” Smalltalk VM… linked list of Context objects Want to use the hardware stack Want to store each Context as a “stack frame” Contexts are usually allocated in LIFO (stack) order. Not usually accessed as an object

Smalltalk Implementation Harry Porter, October Allocating Contexts on the Hardware Stack The hardware supports stacks & procedure CALLs well. “stack frame” = “activation record” Smalltalk VM… linked list of Context objects Want to use the hardware stack Want to store each Context as a “stack frame” Contexts are usually allocated in LIFO (stack) order. Not usually accessed as an object Exception: When debugging, the debugger Asks for a pointer to the current context Treats it as (non-stack) data The Idea:

Smalltalk Implementation Harry Porter, October Allocating Contexts on the Hardware Stack The hardware supports stacks & procedure CALLs well. “stack frame” = “activation record” Smalltalk VM… linked list of Context objects Want to use the hardware stack Want to store each Context as a “stack frame” Contexts are usually allocated in LIFO (stack) order. Not usually accessed as an object Exception: When debugging, the debugger Asks for a pointer to the current context Treats it as (non-stack) data The Idea: Store stack frames on hardware stack, not as objects. When a pointer is generated to the current context… Convert the stack frame into a real object. The Idea: Store stack frames on hardware stack, not as objects. When a pointer is generated to the current context… Convert the stack frame into a real object.

Smalltalk Implementation Harry Porter, October Details Converting a stack frame into a real object… Allocate a new Context object and fill in its fields Convert the program counter (PC) absolute address  byte offset into a CompiledMethod object Contexts point to other Contexts But other Contexts are still on hardware stack Convert all frames into Objects…? No! The Technique: stack-frame hybrid MethodContext

Smalltalk Implementation Harry Porter, October 2009 Caching the Method Dictionary Method Lookup: Given: the receiver’s class the message selector Find: the right CompiledMethod The Idea:

Smalltalk Implementation Harry Porter, October Caching the Method Dictionary Method Lookup: Given: the receiver’s class the message selector Find: the right CompiledMethod The Idea: Use a Hash Table Maintained by the VM (it is not an object) Not in the hash table? Do a full method lookup Add an entry to the hash table Rectangle #draw:on: CompiledMethod key

Smalltalk Implementation Harry Porter, October Inline Method Caching Assume methods are compiled into native code. Code to send a message: CALL MessageSend (arg = selector) A routine that searches for the proper method/routine and then calls it. A machine-language CALL instruction

Smalltalk Implementation Harry Porter, October Inline Method Caching Assume methods are compiled into native code. The Idea: Upon locating the correct routine… Replace the CALL to the “MessageSend” routine … with a CALL straight to the native code routine! Next time we execute the above code, we CALL the right routine immediately. Gradually all message sends are replaced with native code CALL instructions. Code to send a message: CALL MessageSend (arg = selector)

Smalltalk Implementation Harry Porter, October Inline Method Caching Problem: Dynamic Look-Up The receiver’s class determines which method to invoke. Different class?  Different method! Assumption: Approach:

Smalltalk Implementation Harry Porter, October Inline Method Caching Problem: Dynamic Look-Up The receiver’s class determines which method to invoke. Different class?  Different method! Assumption: Any particular SEND will invoke the same method … almost always! Approach:

Smalltalk Implementation Harry Porter, October Inline Method Caching Problem: Dynamic Look-Up The receiver’s class determines which method to invoke. Different class?  Different method! Assumption: Any particular SEND will invoke the same method … almost always! Approach: At the beginning of each method: Check the class of the receiver If it is what this method expects … continue with this method. If the receiver has the wrong class… Perform a full method lookup. Overwrite the CALL (to jump to the correct method next time) Jump to the correct method.

Smalltalk Implementation Harry Porter, October Effectiveness of Optimizations