1. Gradual Memory Management
Jonathan D Goodwin
October 19, 2017

2. Why I am working on memory management.
I am building an open source project:
Interactive 3D worlds accessible via the web browser
web3d.jondgoodwin.com/faq.html
github://jondgoodwin/pegasus3d
Even with 3D hardware, 3D physics & rendering is CPU/memory intensive.
I need 60 fps, with no lag, but still allow safety and convenience of managed code.
Runtime GCs degrade performance and responsiveness.

3. No single memory strategy is adequate.
Language
Memory Strategy
Perf
Responsive
Safe
Flexible
Ease of use
C/C++
Manual 🌑 🌕 C#
Tracing GC
Swift
Ref Count GC 🌓
Rust
Lexical GC
Custom
Hybrid
A proposed hybrid solution can do better:

4. To marry GCs, we need a unifying model.
References:
Variables
Parameters
Fields
Obj/Ref Lifetime Events
Allocate creates first reference.
Program Lifetime
Object
Lifetime
Aliasing creates another reference.
De-aliasing deletes a reference
Free object when lifetime
of all references expires:
RC: reference count = 0
Tracing: Cannot trace from roots
Stack/RAII: end of lexical block
Rust/Lexical GC: ?

5. Rust compiler distinguishes owner vs. borrowed refs
Single, movable owner ref ensures safe free at end of last lexical block
Multiple refs possible via use of lifetime-restricted borrowed refs
struct Point { x: f64, y: f64} fn create() -> Point { Point { x: 5.0, y: 10.0} } // Allocate and return fn length(p: &Point) { (p.x*p.x + p.y*p.y).sqrt() } // Use borrowed reference fn drop(p: Point) { println!("Drop Point( {},{} )", p.x, p.y); } // End of lexical block frees unmoved p’s object fn main() { let p0 = create(); // Move owner ref from create to main’s p0 let p1 = p0; // Aliasing moves owner ref to p1. p0 is no longer usable length(&p1); // Aliasing creates borrowed reference. Owner ref does not move. drop(p1); // Aliasing moves owner ref to drop. p1 is no longer usable }
Owner & borrowed refs become unmanaged pointers at runtime

6. Lexical GC is compile-time: enforced reference constraints eliminate need for runtime GC.
Owner references:
Only one at a time
Move it around
Last one frees
Borrowed references:
Multiple allowed
Lifetime <= ref it borrows from
Object
Lifetime
Owner
References
Borrowed
References
Pro: No runtime bookkeeping cost/lag
Con: Only single-owner data structures
“main()” data leakage
Wrestling with the borrow checker
Can we do better with hybrid approach?

7. To improve flexibility/performance trade-off, adopt hybrid use of lexical and runtime GCs
Usage Guidelines
Tracing: multi-ref or long-lived data
Has runtime GC cost
Lexical: single-ref “working” data
No runtime GC cost
Borrowed refs for object access:
No runtime GC cost (never traced)
Polymorphic across allocators
∴ It’s the default “allocator type”
main() {
tgc a = Point(1,2); // tracing GC allocate
lex b = Point(3,4); // lexical GC allocate
addto(a,b); // use borrowed refs.
} // b freed
addto(m Point, n Point) {
m.x=m.x+n.x;
m.y=m.y+n.y; }

8. The compiler uses declared allocator type to enforce alias rules and behavior.
Allocate
Alias
De-alias
Free
lex: Lexical GC
Allocate from heap.
Move.
Free.
rc: Ref. Count GC
Allocate from heap. count=1.
++count
--count. Free if 0.
tgc: Tracing GC
Trigger GC? Heap alloc. color=white.
local: Stack
Allocate from stack.
n/a
Borrowed ref

9. Next step: Create a language that implements Gradual Memory Management
Implementation challenges:
Minimize allocator type “lexical tax”:
Offer helpful defaults and type inference
Minimize refactoring effort for allocator changes
Transparently support multi-allocator constructors and destructors
Address cross-allocator references
Support arena and object pool allocators
Implement compile-time concurrency safety via permission types
Cone Compiler: github.com/jondgoodwin/cone

10. Paper: www.jondgoodwin.com/pling/gmm.pdf
Q & A ?
Paper:

11. Permission types on references enable compile-time concurrency safety guarantees*
To avoid races, constrain reference: mutability, aliasing, lifetimes or use
Owner references: imm unique mut lock
Borrowed refs: const mutx id
* inspired by Pony, Midori, Rust, and others