This project is for my master's thesis at EECS Northwestern University, which is to evaluate the efficiency and heap layout when running different garbage collectors with different memory allocation patterns, so that we can give suggestions on how to choose the right garbage collector with cogent reasoning and benchmarks.
To build garbage collector that's easy to benchmark and not have to touch interpreter or compiler, I referred to:
- Racket ::
plai/gc2 - Teaching Garbage Collection without Implementing Compilers or Interpreters
- Uniprocessor Garbage Collection Techniques
- On-the-Fly Garbage Collection
- Generational + Mark-Sweep
- Generational + Incremental Mark-Sweep
- Direct Mapped (E=1)
- Direct Mapped (E=2)
- Write-through
- Write-back
- flat only
- pair
- list
- balanced tree
- unbalanced tree with nodes all linked by
firstofcons - closure
- vector
- struct
- mixer
- flat
- pair
- closure
- vector
- structure type
- structure instance
- number
- symbol
- char
- string
- bytes
- eof-object
- regexp
- boolean
- void
- empty
- closure-code
plai/gc2/mutatorinterpret programs fromracketsyntax to gc level, but it is not that extensible. As the syntax it supports is limited and there's no easy to include libraries by callingrequirebut have to add function wrappers insideplai/gc2/mutator.rkt.- Incremental Collector is not that incremental. Free and Mark white objects are done in one scan.
stringandregexp,byte-regexpshould not be stored as heap values but instead in their own data types.