Bent Thomsen Department of Computer Science Aalborg University

Bent Thomsen Department of Computer Science Aalborg University
Languages and Compilers (SProg og Oversættere) Lecture 12 Heap Management and Garbage Collection Bent Thomsen Department of Computer Science Aalborg University Bør revideres til færre slides With acknowledgement to Norm Hutchinson, Patrick Earl, Ethan Henry, Simon Leonard and Jack Newton whose slides this lecture is based on.

The “Phases” of a Compiler
Source Program Syntax Analysis Error Reports Abstract Syntax Tree Contextual Analysis Error Reports Decorated Abstract Syntax Tree Code Generation Last lecture Object Code

Low-level Language Processor
Remember Lecture 10 How to model high-level computational structures and data structures in terms of low-level memory and machine instructions. High Level Program Expressions Records Procedures Methods Arrays Variables Objects How to model ? Low-level Language Processor Registers Bits and Bytes Machine Stack Machine Instructions

Sometimes it goes the other way round
How to reflect low-level memory and machine data structures in terms of high-level computational structures. High Level Program Pointers References Objects How to model ? Low-level Language Processor Registers Bits and Bytes Indirect addressing

Memory usage RECAP: we have seen 2 storage allocation models so far:
static allocation code segment global variables exist “forever” stack allocation local variables and arguments for procedures and functions lifetime follows procedure activation NEXT: Dynamic allocation, also called Heap Storage Some programs may ask for and get memory allocated on arbitrary points during execution When this memory is no longer used it should be freed

Heap Storage Memory allocation under explicit programmatic control
C malloc, C++ / Pascal / Java / C# new operation. Memory allocation implicit in language constructs Lisp, Scheme, Haskell, SML, … most functional languages Autoboxing/unboxing in Java 1.5 and C# Deallocation under explicit programmatic control C, C++, Pascal Deallocation implicit Java, C#, Lisp, Scheme, Haskell, SML, …

Heap Storage Deallocation
Explicit versus Implicit Deallocation In explicit memory management, the program must explicitly call an operation to release memory back to the memory management system. In implicit memory management, heap memory is reclaimed automatically by a “garbage collector”. Examples: Implicit: Java, Scheme Explicit: Pascal and C To free heap memory a specific operation must be called. Pascal ==> dispose C ==> free C++ ==> delete Implicit and Explicit: Ada Deallocation on leaving scope

How does things become garbage?
int *p, *q; … p = malloc(sizeof(int)); p = q; Newly created space becomes garbage for(int i=0;i<10000;i++){ SomeClass obj= new SomeClass(i); System.out.println(obj); } Creates objects, which becomes garbage just after the print

Problem with explicit heap management
int *p, *q; … p = malloc(sizeof(int)); q = p; free(p); Dangling pointer in q now float myArray[100]; p = myArray; *(p+i) = … //equivalent to myArray[i] They can be hard to recognize

OO Languages and heap allocation
Objects are a lot like records and instance variables are a lot like fields. => The representation of objects is similar to that of a record. Methods are a lot like procedures. => Implementation of methods is similar to routines. But… there are differences: Objects have methods as well as instance variables, records only have fields. Thus methods have to somehow know what object they are associated with (so that methods can access the object’s instance variables) Object lifetime not necessarily tied to program nesting structure !!

Representation of a simple Java object
A simple Java object (no inheritance) class Point { int x,y; public Point(int x, int y) { this.x=x; this.y=y; } public void move(int dx, int dy) { x=x+dx; y=y+dy; public float area() { ...} public float dist(Point other) { ... } (1) (2) (3) (4)

Representation of a simple Java object
A simple Java object (no inheritance) new allocates an object in the heap Point p = new Point(2,3); Point q = new Point(0,0); class x y 2 3 p q class x y Point class constructor(1) Point move area dist method(2) method(3) method(4)

Objects can become garbage
Point p = new Point(2,3); Point q = new Point(0,0); p = q;

Stacks and dynamic allocations are incompatible
Why can’t we just do dynamic allocation within the stack? Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, 2000

Stack allocated objects in C++
MyObj* myobj = new MyObj(); Must later be freed with delete myobj Whereas myobj = MyObj()is freed as soon as the code exits current block (because myobj is allocated on the stack) Note in C# stack alloacted obejcts are called structs

Automatic Storage Deallocation (Garbage Collection)
Everybody probably knows what a garbage collector is. But here are two “one liners” to make you think again about what a garbage collector really is! 1) Garbage collection provides the “illusion of infinite memory”! 2) A garbage collector predicts the future! It’s a kind of magic! :-) Let us look at how this magic is done!

Where to put the heap? The heap is an area of memory which is dynamically allocated. Like a stack, it may grow and shrink during runtime. Unlike a stack it is not a LIFO => more complicated to manage In a typical programming language implementation we will have both heap-allocated and stack allocated memory coexisting. Q: How do we allocate memory for both

Where to put the heap? A simple approach is to divide the available memory at the start of the program into two areas: stack and heap. Another question then arises How do we decide what portion to allocate for stack vs. heap ? Issue: if one of the areas is full, then even though we still have more memory (in the other area) we will get out-of-memory errors Q: Isn’t there a better way?

Where to put the heap? Q: Isn’t there a better way?
A: Yes, there is an often used “trick”: let both stack and heap share the same memory area, but grow towards each other from opposite ends! SB Stack memory area ST Stack grows downward Heap can expand upward HT Heap memory area HB

How to keep track of free memory?
Stack is LIFO allocation => ST moves up/down everything above ST is in use/allocated. Below is free memory. This is easy! But … Heap is not LIFO, how to manage free space in the “middle” of the heap? SB Free HT Allocated Mixed: Allocated and Free reuse? ST Free HB

How to manage free space in the “middle” of the heap? => keep track of free blocks in a data structure: the “free list”. For example we could use a linked list pointing to free blocks. freelist A freelist! Good idea! But where do we find the memory to store this data structure? HT Free Next Free Next Free Next HB

Q: Where do we find the memory to store a freelist data structure? A: Since the free blocks are not used for anything by the program => memory manager can use them for storing the freelist itself. HT HF free block size HF next free HB

Why Garbage Collect? Software Engineering
Garbage collection increases abstraction level of software development. Simplified interfaces and decreases coupling of modules. Studies have shown a significant amount of development time is spent on memory management bugs [Rovner, 1985]. Mesa System 40%

Implicit memory management
Current trend of modern programming language development: to give only implicit means of memory management to a programmer: The constant increase of hardware memory justifies the policy of automatic memory management The explicit memory management distracts programmer from his primary tasks: let everyone do what is required of them and nothing else! The philosophy of high-level languages conforms to the implicit memory management Other arguments for implicit memory management: Anyway, a programmer cannot control memory management for temporary variables! The difficulties of combination of two memory management mechanisms: system and the programmer’s The history repeats: in 70’s people thought that the implicit memory management had finally replaced all other mechanisms

Classes of Garbage Collection Algorithms
Direct Garbage Collectors: a record is associated with each node in the heap. The record for node N indicates how many other nodes or roots point to N. Indirect/Tracing Garbage Collectors: usually invoked when a user’s request for memory fails because the free list is exhausted. The garbage collector visits all live nodes, and returns all other memory to the free list. If sufficient memory has been recovered from this process, the user’s request for memory is satisfied. For reference counters, residency is not an issue. Tracing collectors will be invoked more frequently if the occupancy of the heap is high.

Terminology Roots: values that a program can manipulate directly (i.e. values held in registers, on the program stack, and global variables.) Node/Cell/Object: an individually allocated piece of data in the heap. Children Nodes: the list of pointers that a given node contains. Live Node: a node whose address is held in a root or is the child of a live node. Garbage: nodes that are not live, but are not free either. Garbage collection: the task of recovering (freeing) garbage nodes. Mutator: The program running alongside the garbage collection system.

Types of garbage collectors
The “Classic” algorithms Reference counting Mark and sweep Copying garbage collection Generational garbage collection Incremental Tracing garbage collection

Reference Counting Every cell has an additional field: the reference count. This field represents the number of pointers to that cell from roots or heap cells. Initially, all cells in the heap are placed in a pool of free cells, the free list. When a cell is allocated from the free list, its reference count is set to one. When a pointer is set to reference a cell, the cell’s reference count is incremented by 1; if a pointer is to the cell is deleted, its reference count is decremented by 1. When a cell’s reference count reaches 0, its pointers to its children are deleted and it is returned to the free list.

Reference Counting Example
1 2 1 1 1

1 2 1 1 1 1

1 Returned to free list 1 2 1 1 1

Reference Counting: Advantages and Disadvantages
Garbage collection overhead is distributed. Locality of reference is no worse than mutator. Free memory is returned to free list quickly.

Reference Counting: Advantages and Disadvantages
High time cost (every time a pointer is changed, reference counts must be updated). In place of a single assignment x.f = p: Storage overhead for reference counter can be high. Unable to reclaim cyclic data structures. If the reference counter overflows, the object becomes permanent. z = x.f c = z.count c = c – 1 z.count = c If c = 0 call putOnFreeList(z) x.f = p c = p.count c = c + 1 p.count = c

Reference Counting: Cyclic Data Structure - Before
1 2 2 1

Reference Counting: Cyclic Data Structure – After
1 1 2 1

Deferred Reference Counting
Optimisation Cost can be improved by special treatment of local variables. Only update reference counters of objects on the stack at fixed intervals. Reference counts are still affected from pointers from one heap object to another.

Mark-Sweep The first tracing garbage collection algorithm
Garbage cells are allowed to build up until heap space is exhausted (i.e. a user program requests a memory allocation, but there is insufficient free space on the heap to satisfy the request.) At this point, the mark-sweep algorithm is invoked, and garbage cells are returned to the free list. Performed in two phases: Mark: identifies all live cells by setting a mark bit. Live cells are cells reachable from a root. Sweep: returns garbage cells to the free list.

Mark and Sweep Garbage Collection
before gc mark as free phase SB SB ST ST HT HT X e e X d d c c X b X b X a a HB HB

mark as free phase mark reachable collect free SB SB SB ST HB HT e b d X ST ST HT HT X X X e e X X X d d c c X X X b X X b X X a a HB HB

Mark-Sweep Example Returned to free list

Algorithm pseudo code: void garbageCollect() { mark all heap variables as free for each frame in the stack scan(frame) for each heapvar (still) marked as free add heapvar to freelist } void scan(region) { for each pointer p in region if p points to region marked as free then mark region at p as reachable scan(region at p ) Q: This algorithm is recursive. What do you think about that?

Mark-Sweep: Advantages and Disadvantages
Cyclic data structures can be recovered. Tends to be faster than reference counting.

Computation must be halted while garbage collection is being performed Every live cell must be visited in the mark phase, and every cell in the heap must be visited in the sweep phase. Garbage collection becomes more frequent as residency of a program increases. May fragment memory.

Has negative implications for locality of reference. Old objects get surrounded by new ones (not suited for virtual memory applications). However, if objects tend to survive in clusters in memory, as they apparently often do, this can greatly reduce the cost of the sweep phase.

Mark-Compact Collection
Remedy the fragmentation and allocation problems of mark-sweep collectors. Two phases: Mark: identical to mark sweep. Compact: marked objects are compacted, moving most of the live objects until all the live objects are contiguous.

Heap Compaction To fight fragmentation, some memory management algorithms perform “heap compaction” once in a while. before after HT a HF HT a b c b c d d HB HB

Mark-Compact: Advantages and Disadvantages
The contiguous free area eliminates fragmentation problem. Allocating objects of various sizes is simple. The garbage space is "squeezed out", without disturbing the original ordering of objects. This improves locality.

Mark-Compact: Advantages and Disadvantages
Requires several passes over the data are required. "Sliding compactors" takes two, three or more passes over the live objects. One pass computes the new location Subsequent passes update the pointers to refer to new locations, and actually move the objects

Copying Garbage Collection
Like mark-compact, copying garbage collection does not really "collect" garbage. Rather it moves all the live objects into one area and the rest of the heap is known to be available. Copying collectors integrate the traversal and the copying process, so that objects need only be traversed once. The work needed is proportional to the amount of live data (all of which must be copied).

Semispace Collector Using the Cheney Algorithm
The heap is subdivided into two contiguous subspaces (FromSpace and ToSpace). During normal program execution, only one of these semispaces is in use. When the garbage collector is called, all the live data are copied from the current semispace (FromSpace) to the other semispace (ToSpace).

B C D FromSpace ToSpace

B C D A B C D FromSpace ToSpace

Once the copying is completed, the ToSpace is made the "current" semispace. A simple form of copying traversal is the Cheney algorithm. The immediately reachable objects from the initial queue of objects for a breadth-first traversal. A scan pointer is advanced through the first object location by location. Each time a pointer into FromSpace is encountered, the referred-to-object is transported to the end of the queue and the pointer to the object is updated. Mangler noget I første bullet

Multiple paths must not be copied to tospace multiple times. When an object is transported to tospace, a forwarding pointer is installed in the old version of the object. The forwarding pointer signifies that the old object is obsolete and indicates where to find the new copy.

Copying Garbage Collection: Advantages and Disadvantages
Allocation is extremely cheap. Excellent asymptotic complexity. Fragmentation is eliminated. Only one pass through the data is required.

Copying Garbage Collection: Advantages and Disadvantages
The use of two semi-spaces doubles memory requirement Poor locality. Using virtual memory will cause excessive paging.

Problems with Simple Tracing Collectors
Difficult to achieve high efficiency in a simple garbage collector, because large amounts of memory are expensive. If virtual memory is used, the poor locality of the allocation/reclamation cycle will cause excessive paging. Even as main memory becomes steadily cheaper, locality within cache memory becomes increasingly important.

Problems with Simple Tracing Collectors
With a simple semispace copy collector, locality is likely to be worse than mark-sweep. The memory issue is not unique to copying collectors. Any efficient garbage collection involves a trade-off between space and time. The problem of locality is an indirect result of the use of garbage collection.

Generational Garbage Collection
Attempts to address weaknesses of simple tracing collectors such as mark-sweep and copying collectors: All active data must be marked or copied. For copying collectors, each page of the heap is touched every two collection cycles, even though the user program is only using half the heap, leading to poor cache behavior and page faults. Long-lived objects are handled inefficiently.

Generational garbage collection is based on the generational hypothesis: Most objects die young. As such, concentrate garbage collection efforts on objects likely to be garbage: young objects.

Generational Garbage Collection: Object Lifetimes
When we discuss object lifetimes, the amount of heap allocation that occurs between the object’s birth and death is used rather than the wall time. For example, an object created when 1Kb of heap was allocated and was no longer referenced when 4 Kb of heap data was allocated would have lived for 3Kb. Typically, between 80 and 98 percent of all newly-allocated heap objects die before another megabyte has been allocated.

Objects are segregated into different areas of memory based on their age. Areas containing newer objects are garbage collected more frequently. After an object has survived a given number of collections, it is promoted to a less frequently collected area.

Generational Garbage Collection: Example
Initial state. Point out memory usage, memory divisions. We are going to overwrite the first root node with a pointer to a new object, R. A S Root Set Memory Usage Memory Usage Old Generation New Generation

Generational Garbage Collection: Example (Continued)
Note memory is almost used up. R now makes a request for a new node, D, to be created but there is insufficient memory. A garbage collection is initiated. A S Root Set Memory Usage Memory Usage Old Generation New Generation

Generational Garbage Collection: Example (Continued)
All objects in New generation are moved to old generation. Garbage nodes are freed. Allocation for D is successfully completed. A S Root Set Memory Usage Memory Usage Old Generation New Generation

Generational Garbage Collection: Example
This example demonstrates several interesting characteristics of generational garbage collection: The young generation can be collected independently of the older generations (resulting in shorter pause times). An intergenerational pointer was created from R to D. These pointers must be treated as part of the root set of the New Generation. Garbage collection in the new generation result in S becoming unreachable, and thus garbage. Garbage in older generations (sometimes called tenured garbage) can not be reclaimed via garbage collections in younger generations.

Generational Garbage Collection: Implementation
Usually implemented as a copying collector, where each generation has its own semispace: FromSpace FromSpace ToSpace ToSpace Old Generation New Generation

Generational Garbage Collection: Issues
Choosing an appropriate number of generations: If we benefit from dividing the heap into two generations, can we further benefit by using more than two generations? Choosing a promotion policy: How many garbage collections should an object survive before being moved to an older generation? Tracking intergenerational pointers: Inter-generational pointers need to be tracked, since they form part of the root set for younger generations. Collection Scheduling Can we attempt to schedule garbage collection in such a way that we minimize disruptive pauses?

Generational Garbage Collection: Multiple Generations

Generational Garbage Collection: Multiple Generations
Advantages: Keeps youngest generation’s size small. Helps address mistakes made by the promotion policy by creating more intermediate generations that still get garbage collected fairly frequently. Disadvantages: Collections for intermediate generations may be disruptive. Tends to increase number of inter-generational pointers, increasing the size of the root set for younger generations. Most generational collectors are limited to just two or three generations.

Generational Garbage Collection: Promotion Policies
A promotion policy determines how many garbage collections cycles (the cycle count) an object must survive before being advanced to the next generation. If the cycle count is too low, objects may be advanced too fast; if too high, the benefits of generational garbage collection are not realized With a cycle count of just one, objects created just before the garbage collection will be advanced, even though the generational hypothesis states they are likely to die soon. Increasing the cycle count to two denies advancement to recently created objects. Under most conditions, increasing the cycle count beyond two does not significantly reduce the amount of data advanced.

Generational Garbage Collection: Inter-generational Pointers
Inter-generational pointers can be created in two ways: When an object containing pointers is promoted to an older generation. When a pointer to an object in a newer generation is stored in an object. The garbage collector can easily detect promotion-caused inter-generational pointers, but handling pointer stores is a more complicated task. Pointer stores can be tracked via the use of a write barrier: Pointer stores must be accompanied by extra bookkeeping instructions that let the garbage collector know of pointers that have been updated. Often implemented at the compiler level.

Generational Garbage Collection: Collection Scheduling
Generational garbage collection aims to reduce pause times. When should these (hopefully short) pause times occur? Two strategies exist: Hide collections when the user is least likely to notice a pause, or Trigger efficient collections when there is likely to be lots of garbage to collect.

Generational Garbage Collection: Advantages
In practice it has proven to be an effective garbage collection technique. Minor garbage collections are performed quickly. Good cache and virtual memory behaviour.

Sun HotSpot Sun JDK 1.0 used mark-compact
Sun improved memory management in the Java 2 VMs (JDK 1.2 and on) by switching to a generational garbage collection scheme The heap is separated into two regions: New Objects Old Objects

New Object Region The idea is to use a very fast allocation mechanism and hope that objects all become garbage before you have to garbage collect The New Object Regions is subdivided into three smaller regions: Eden, where objects are allocated 2 “Survivor” semi-spaces: “From” and “To”

New Object Region The Eden area is set up like a stack - an object allocation is implemented as a pointer increment When the Eden area is full, the GC does a reachability test and then copies all the live objects from Eden to the “To” region The labels on the regions are swapped “To” becomes “From” - now the “From” area has objects

New Object Region The next time Eden fills, objects are copied from both the “From” region and Eden to the “To” area There’s a “Tenuring Threshold” that determines how many times an object can be copied between survivor spaces before it’s moved to the Old Object region Note that one side-effect is that one survivor space is always empty

Old Object Region The old object region is for objects that will have a long lifetime The hope is that because most garbage is generated by short-lived objects that you won’t need to GC the old object region very often

New Object Region Old Object Region Eden SS1 SS2 Old First GC Eden SS1 SS2 Old Eden SS2 SS1 Old Second GC Eden SS2 SS1 Old Eden SS2 SS1 Old

Generational Garbage Collection: Disadvantages
Performs poorly if any of the main assumptions are false: That objects tend to die young. That there are relatively few pointers from old objects to young ones. Frequent pointer writes to older generations will increase the cost of the write barrier, and possibly increase the size of the root set for younger generations.

Incremental Tracing Collectors
Program (Mutator) and Garbage Collector run concurrently. Can think of system as similar to two threads. One performs collection, and the other represents the regular program in execution. Can be used in systems with real-time requirements. For example, process control systems. allow mutator to do its job without destroying collector’s possibilities for keeping track of modifications of the object graph, and at the same time allowing collector to do its job without interfering with mutator

Coherence & Conservatism
Coherence: A proper state must be maintained between the mutator and the collector. Conservatism: How aggressive the garbage collector is at finding objects to be deallocated.

Tricolouring White – Not yet traversed. A candidate for collection.
Black – Already traversed and found to be live. Will not be reclaimed. Grey – In traversal process. Defining characteristic is that it’s children have not necessarily been explored.

The Tricolour Abstraction

Incremental Tracing Collectors Overview
Baker’s Algorithm Based on Cheney’s copy-collect-algorithm Based on tricolouring Principle: whenever mutator accesses a pointer to a white object the object is coloured grey this ensures that mutator never points to a white object, hence part 1 of the invariant holds At every read mutator does, the invariant must be checked (expensive), if this is the case the object must be forwarded (using the standard forward algorithm) to to-space There are variants: read-barrier write-barrier synchronising on page-level

Garbage Collection: Summary
Method Conservatism Space Time Fragmentation Locality Mark Sweep Major Basic 1 traversal + heap scan Yes Fair Mark Compact Many passes of heap No Good Copying Two Semispaces 1 traversal Poor Reference Counting Reference count field Constant per Assignment Very Good Deferred Reference Counting Only for stack variables Reference Count Field Incremental Varies depending on algorithm Varies Can be Guaranteed Real-Time Generational Variable Segregated Areas Varies with number of live objects in new generation Yes (Non-Copying) No (Copying) Tracing Incremental

Comparing Garbage Collection Algorithms
Directly comparing garbage collection algorithms is difficult – there are many factors to consider. Some factors to consider: Cost of reclaiming cells Cost of allocating cells Storage overhead How does the algorithm scale with residency? Will user program be suspended during garbage collection? Does an upper bound exist on the pause time? Is locality of data structures maintained (or maybe even improved?) For reference counters, residency is not an issue. Tracing collectors will be invoked more frequently if the occupancy of the heap is high.

Comparing Garbage Collection Algorithms
Zorn’s study in 1989/93 compared garbage collection to explicit deallocation: Non-generational Between 0% and 36% more CPU time. Between 40% and 280% more memory. Generational garbage collection Between 5% to 20% more CPU time. Between 30 and 150% more memory. Wilson feels these numbers can be improved, and they are also out of date. A well implemented garbage collector will slow a program down by approximately 10 percent relative to explicit heap deallocation.

Garbage Collection: Conclusions
Despite this cost, garbage collection a feature in many widely used languages: Lisp (1959) SML, Haskell, Miranda (1980-) Perl (1987) Java (1995) C# (2001) Microsoft’s Common Language Runtime (2002)

Different choices for different reasons
JVM Sun Classic: Mark, Sweep and Compact SUN HotSpot: Generational (two generation + Eden) -Xincgc an incremental collector that breaks that old-object region into smaller chunks and GCs them individually -Xconcgc Concurrent GC allows other threads to keep running in parallel with the GC BEA jRockit JVM: concurrent, even on another processor IBM: Improved Concurrent Mark, Sweep and Compact with a notion of weak references Real-Time Java Scoped LTMemory, VTMemory, RawMemory .Net CLR Managed and unmanaged memory (memory blob) PC version: Self-tuning Generation Garbage Collector .Net CF: Mark, Sweep and Compact

Garbage Collection: Conclusions
Relieves the burden of explicit memory allocation and deallocation. Software module coupling related to memory management issues is eliminated. An extremely dangerous class of bugs is eliminated. The compiler generates code for allocating objects The compiler must also generate code to support GC The GC must be able to recognize root pointers from the stack The GC must know about data-layout and objects descriptors The choice of Garbage Collector algorithm has to take many factors into consideration

Other Issues in Memory Management
When Stack and Heap are not enough Register allocation in C RTSJ Scoped Memory Region Based Memory Managent Programmers (soon) have to be aware of Memory Hierarchies

Register variable in C Ex: register float a = 0 ;
register provides a hint to the compiler that you think a variable will be frequently used compiler is free to ignore register hint if ignored, the variable is equivalent to an auto variable with the exception that you may not take the address of a register (since, if put in a register, the variable will not have an address) rarely used, since any modern compiler will do a better job of optimization than most programmers

RTSJ: Three Types of Memory
Heap memory Standard Java Heap Immortal memory Immortal memory, exists for the life of the application Scoped Memory A way to reclaim memory without a garbage collector Well the RTSJ breaks the memory space into three possible types. The first type is our standard heap (as you have noticed, we haven’t gotten rid of any of the things that would make traditional Java applications runs such as the garbage collector, the heap, the normal thread. This is both part of the RTSJ’s mission, and a way to make the developers of the non-RT parts of an application happy), The second type of memory is immortal memory. Immortal memory is what it sounds like. Objects in immortal memory are created an exist for the lifetime of the application. Great if we want to avoid interacting with the garbage collector, but no so great for long-running applications, like for example, many real-time applications. So that brings us to scoped memory, one of the most important new features of the rtsj, and potentially one of the trickiest for developers to learn to use properly. It is a way to avoid interaction with the garbage collector and yet still reclaim allocated memory throughout the lifetime of the application.

Scoped Memory Scopes have fixed lifetimes Lifetime starts here:
scopedMemArea.enter() { … } Lifetime ends: So what exactly is scoped memory then? Scoped memory is really a form of region-based memory management. A memory scope is an area of memory that can contain objects, and these objects aren’t reclaimed individually but rather in one fell swoop. This reclamation occurs at the end of the scope’s lifetime, and this lifetime is defined lexically. In a RTSJ application that uses scoped memory, you can call the enter method on a particular memory area, and then the code that is given in the following curly braces is executed within that memory area. So in other words a memory scope’s life begins at the left curly brace and ends at the right curly brace. You can also, when constructing a new thread, explicitly state that it’s run method will execute inside a particular scope. In a multithreaded real-time system, a scope can't be reclaimed until all threads have reached the closing curly brace.

Scoped Memory All calls to new inside a scope, create an object inside of that scope When the scope’s lifetime ends, all objects within are destroyed

Scope Nesting Scopes can be nested scopedMemArea.enter() { ...
anotherScope.enter() { } In addition to this, scopes can be nested. A thread can enter a scope from within another scope, and this defines a nested relationship of scopes. The outer scope is referred to as the parent scope of the inner scope which is the child. Also, because the right curly brace of the child scope will arrive before the right curly brace of the parent scope, the parent scope will necessarily have a longer lifetime than the child scope. (perhaps somewhat paradoxically)

Memory Safety Must ensure RTSJ ensures this with run-time checks
No dangling pointers Objects can’t refer to shorter lived objects RTSJ ensures this with run-time checks SCJ ensures this with annotations and static checks PJ must ensure this with static analysis and limiting scopes to follow program structure heap immortal parent child I would argue that a run-time check here is a problem: An overhead on all assignment statements should probably be avoided in performance conscious systems It’s unneccessary

Region Based memory management
Compiler (especially Type inference) automatically detects scopes or regions May require programmer to annotate types May sometimes have worse behaviour than GC and heap

What is the most expensive operation in this line of C code?
int x = (3.14 * r) + (x * y);

A programmer’s view of memory
This model was pretty accurate in 1985. Processors (386, ARM, MIPS, SPARC) all ran at 1–10MHz clock speed and could access external memory in 1 cycle; and most instructions took 1 cycle. Indeed the C language was as expressively time-accurate as a language could be: almost all C operators took one or two cycles. But this model is no longer accurate!

A modern view of memory timings
So what happened? On-chip computation (clock-speed) sped up faster (1985–2005) than off-chip communication (with memory) as feature sizes shrank. The gap was filled by spending transistor budget on caches which (statistically) filled the mismatch until 2005 or so. Techniques like caches, deep pipelining with bypasses, and superscalar instruction issue burned power to preserve our illusions. 2005 or so was crunch point as faster, hotter, single-CPU Pentiums were scrapped. These techniques had delayed the inevitable.

The Current Mainstream Processor
1024 processors by 2017 if Moore’s law still apply Will scale to 2, 4 maybe 8 processors. But ultimately shared memory becomes the bottleneck (1024 processors?!?).

Hardware will change Cell GPU Others?
Multi-core with 1 PPC + 8(6) SPE (SIMD) 3 level memory hierarchy broadcast communication GPU 256 SIMD HW treads Data parallel memory Others?

Partitioned Global Address Space: (PGAS)
Multiple threads share at least a part of a global address space. Can access local and remote data with same mechanisms. Can distinguish between local and remote data with some sort of typing. Languages X10, Chapel and Fortress

Conclusions Understanding Memory Management is as important as ever!!
Huge improvements in GC technology New ways of “safe” programmer controlled Memory Management are being proposed Memory Hierarchies are beginning to be reflected in languages

Bent Thomsen Department of Computer Science Aalborg University

Similar presentations

Presentation on theme: "Bent Thomsen Department of Computer Science Aalborg University"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Bent Thomsen Department of Computer Science Aalborg University

Similar presentations

Presentation on theme: "Bent Thomsen Department of Computer Science Aalborg University"— Presentation transcript:

Similar presentations

About project

Feedback