slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Experience with Safe Memory Management in Cyclone PowerPoint Presentation
Download Presentation
Experience with Safe Memory Management in Cyclone

Loading in 2 Seconds...

play fullscreen
1 / 36

Experience with Safe Memory Management in Cyclone - PowerPoint PPT Presentation


  • 148 Views
  • Uploaded on

Michael Hicks University of Maryland, College Park Joint work with Greg Morrisett - Harvard Dan Grossman - UW Trevor Jim - AT&T. Experience with Safe Memory Management in Cyclone. Cyclone. Derived from C, having similar goals

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Experience with Safe Memory Management in Cyclone' - thane-fisher


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1
Michael Hicks

University of Maryland, College Park

Joint work with

Greg Morrisett - Harvard

Dan Grossman - UW

Trevor Jim - AT&T

Experience with Safe Memory Management in Cyclone
cyclone
Cyclone
  • Derived from C, having similar goals
    • Exposes low-level data representations, provides fine-grained operations
  • But safe
    • Restrictions to C (e.g., (int *)1 not allowed)
    • Additions and types to regain flexibility
  • Today: balancing safety and flexibility when managing memory
goal programmer control
Goal: Programmer Control
  • Many memory management choices
    • Garbage collection
    • Stack allocation
    • malloc/free
    • Reference counting (Linux, COM)
    • Arenas (bulk free) (Apache, LCC)
  • Depends on the application
unifying theme region types
Unifying Theme: Region types
  • Conceptually divide memory into regions
    • Different kinds of regions (e.g., not just bulk-free)
  • Associate every pointer with a region
  • Prevent dereferencing pointers into dead regions

int *`r x;// x points into region `r

*x = 3; // deref allowed if `r is live

(inference often obviates annotations `r)

Liveness by type & effects system (Tofte&Talpin)

outline
Outline
  • Motivation and basic approach
  • Regions description
    • Basics: LIFO arenas, stack and heap regions
    • Unique and reference-counted pointers
    • Dynamic arenas
  • Programming experience
  • Experimental measurements
  • Conclusions
lifo arenas
LIFO Arenas
  • Dynamic allocation mechanism
  • Lifetime of entire arena is scoped
    • At conclusion of scope, all data allocated in the arena is freed.
lifo arena example
LIFO Arena Example

FILE *infile = …

Image *i;

if (tag(infile) == HUFFMAN) {

region<`r> h; // region `r created

struct hnode *`r huff_tree;

huff_tree = read_tree(h,infile); // allocates with h

i = decode_image(infile,huff_tree,…);

// region `r deallocated upon exit of scope

} else …

stack and heap regions
Stack and Heap Regions
  • Stack regions
    • Degenerate case of LIFO arena which does not allow dynamic allocation
    • Essentially activation records
  • Heap region
    • A global region `H that is always live
    • Like a LIFO arena that never dies; objects reclaimed by a garbage collector
scoped regions summary
Scoped Regions Summary

See PLDI `02 paper for more details

benefits
Benefits
  • No runtime access checks
  • Arena/stacks
    • costs are constant-time
      • region allocation
      • region deallocation
      • object creation
    • useful for
      • Temporary data (e.g., local variables)
      • Callee-allocates data (rprintf)
      • Lots of C-style code
limitations
Limitations
  • Lack of control over memory usage
    • Spurious retention of regions and their objects
    • Fragmentation
    • Extra space required by the garbage collector
  • Lack of control over CPU usage
    • Garbage collection is “one-size-fits-all”
      • Hard to tune
    • Cannot avoid GC in some cases: LIFO arenas not expressive enough
      • E.g., objects with overlapping lifetimes
overcoming the limitations
Overcoming the Limitations
  • Allow greater control over lifetimes
    • Object lifetimes
      • Unique pointers and reference-counted pointers
    • Arena lifetimes
      • Dynamic arenas
  • But not for nothing ...
    • Restrictions on aliasing
    • Possibility of memory leaks
unique region
Unique Region
  • Distinguished region name `U
  • Individual objects can be freed manually
  • An intraprocedural, flow-sensitive analysis
    • ensures that a unique pointer is not used after it is consumed (i.e. freed)
    • treats copies as destructive; i.e. only one usable copy of a pointer to the same memory
    • Loosely based on affine type systems
unique pointer example
Unique Pointer Example

void foo() {

int *`U x = malloc(sizeof(int));

int *`U y = x; // consumes x

*x = 5;// disallowed

free(y); // consumes y

*y = 7;// disallowed

}

temporary aliasing
Temporary Aliasing
  • Problem: Non-aliasing too restrictive
  • Partial solution: Allow temporary, lexically-scoped aliasing under acceptable conditions
    • Makes unique pointers easier to use
    • Increases code reuse
alias construct
Alias construct

extern void f(int *`r x); // `r any scoped region

void foo() {

int *`U x = malloc(sizeof(int));

*x = 3;

{ alias <`r>int *`r y = x;// `r fresh

f(y); // y aliasable, but x consumed

} // x unconsumed

free(x);

}

alias inference
Alias inference

extern void f(int *`r x); // `r any scoped region

void foo() {

int *`U x = malloc(sizeof(int));

*x = 3;

f(x); // alias inserted here automatically

free(x);

}

reference counted pointers
Reference-counted Pointers
  • Distinguished region `RC
  • Objects allocated in `RC have hidden reference-count field
  • Aliasing tracked as with unique pointers. Explicit aliasing/freeing via

`a *`RCalias_refptr(`a *`RC);

void drop_refptr(`a *`RC);

reference counting example
Reference-counting Example

struct conn * `RC cmd_pasv(struct conn * `RC c) {

struct ftran * `RC f;

int sock = socket(...);

f = alloc_new_ftran(sock,alias_refptr(c));

c->transfer = alias_refptr(f);

listen(f->sock, 1);

f->state = 1;

drop_refptr(f);

return c;

}

ensuring uniformity and reuse
Ensuring Uniformity and Reuse
  • Many different idioms could be hard to use
    • Duplicated library functions
    • Hard-to-change application code
  • We have solved this problem by
    • Using region types as a unifying theme
    • Region polymorphism with kinds
      • E.g., functions independent of arguments’ regions
    • All regions can be treated as if lexical
      • Temporarily, under correct circumstances
      • Using alias and open constructs
programming experience
Programming Experience

Boa web server

BetaFTPD ftp server

Epic image compression

Kiss-FFT portable fourier transform

MediaNet streaming overlay network

CycWeb web server

CycScheme scheme interpreter

experimental measurements
Experimental Measurements
  • Platform
    • Dual 1.6 GHz AMD Athlon MP 2000
      • 1 GB RAM
      • Switched Myrinet
    • Linux 2.4.20 (RedHat)
  • Software
    • C code: gcc 3.2.2
    • Cyclone code: cyclone 0.8
    • GC: BDW conservative collector 6.2a4
    • malloc/free: Lea allocator 2.7.2
bottom line
Bottom Line
  • CPU time
    • Most applications do not benefit from switching from BDW GC to manual approach
    • MediaNet is the exception
  • Memory usage
    • Can reduce memory footprint and working set size by 2 to 10 times by using manual techniques
related work
Related Work
  • Regions
    • ML-Kit (foundation for Cyclone’s type system)
    • RC
    • Reaps
    • Walker/Watkins
  • Uniqueness
    • Wadler, Walker/Watkins, Clean
    • Alias types, Calculus of Capabilities, Vault
    • Destructive reads (e.g., Boyland)
future work
Future Work
  • Tracked pointers sometimes painful; want
    • Better inference (e.g. for alias)
    • Richer API (restrict; autorelease)
  • Prevent leaks
    • unique and reference-counted pointers
  • Specified aliasing
    • for doubly-linked lists, etc.
  • Concurrency
conclusions
Conclusions
  • High degree of control, safely:
  • Sound mechanisms for programmer-controlled memory management
    • Region-based vs. object-based deallocation
    • Manual vs. automatic reclamation
  • Region-annotated pointers within a simple framework
    • Scoped regions unifying theme (alias,open)
    • Region polymorphism, for code reuse
more information
More Information
  • Cyclone homepage
    • http://www.cs.umd.edu/projects/cyclone/
  • Has papers, benchmarks from this paper, and free distribution
    • Read about it, write some code!