Manish Goregaokar Manishearth

Three GC pointers: Gc<T>, GcRef<'a, T>, and GcMove<T> (aka GcRoot<T>). T: Trace for all three

GcRef<'a, T> is really just &'a Gc<T> without the extra indirection. Moving on.

Gc<T> is never to be used on the stack. it is only to be used inside struct fields. It implements Trace. On the stack, it must be referred to via GcRef or &Gc

We abuse the fact that rust doesn't let one move out of a borrow to enforce this. The only thing that is allowed is taking borrows of it.

The idea is:

The following gates: plugin, box_syntax, custom_derive, custom_attribute were ignored for this analysis because these are features we don't plan on moving off unless absolutely necessary. Nevertheless, they're not strictly necessary for Servo to work; they just make some code nicer.

The main point of this exercise was to find what unstable APIs Servo uses/needs a lot, which might probably be needed by others too. Most of these have workarounds, and most of these are blocked on trivial things like naming (and could be easily stabilized). While I did remove some unstable usage in Servo, I didn't fix the majority of these even though it was easy to fix because we use nightly anyway (plugins, etc) and it would be nice to end up with the final, polished, performant APIs instead of a slightly more verbose workaround that we'll forget about.

Really common APIs

collections almost everywhere is just blocked on Vec.push_all(). We can immediately use extend() here if we want, or a for loop, but if this

Rust GC Design

GC History

The role of garbage collection (GC) in Rust has been heavily revised during the language's design. It was originally deeply integrated into

Uprooting

We root way too much in DOM. Let's not do that.

Magic DOM might fix a lot of problems here, and we're not certain what the performance hit of this is, so we shouldn't really do anything about this until after that. This is more of a dump of all the ideas that came up in this discussion.

Low hanging fruit: Escape analysis

There are lot of .root()s left over from the pre-dereffable-JS<T> era. These are transitively rooted and aren't being moved, so just using Deref should work. Simple escape analysis can catch these.

Identifying roots

As I understand it, the core of the Rust GC support functionality will be a function that looks like fn gimme_roots() -> Vec<..> or fn walk_roots<F>(f: F) where F: Fn(..). This can be implemented via LLVM stack roots and then walking them.

The first question is: What does the compiler identify as a root? On the flipside, how do GC library writers tell the compiler that something should be included in walk_roots?

Root attribute

(this solution is flawed, skip to the trace trait one if you want) One way to do this is an attribute, #[root] or something.

	Very high level intro to Rust
	Goals: speed, safety, concurency
	Ownership and move semantics
	Zero-cost abstractions

	1.0 is out! (release planned for the day before !!Con)
	What does “stable” mean?
	Semantic versioning
	Release trains (nightly/beta/stable) and rapid release, à la Firefox

	fn rockstar_interview_swap(x: &mut u8, y: &mut u8) {
	// Look, ma, no temporary variables!
	x = x + *y;
	y = x - *y;
	x = x - *y;
	}

	desc: (none)
	cmd: x86_64-unknown-linux-gnu/stage1/bin/rustc --cfg stage1 -O --cfg rtopt --cfg ndebug -C rpath -C prefer-dynamic --target=x86_64-unknown-linux-gnu -D warnings -L x86_64-unknown-linux-gnu/rt -L /home/manishearth/Mozilla/rust/x86_64-unknown-linux-gnu/llvm/Release/lib --out-dir x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib -C extra-filename=-d8ace771 /home/manishearth/Mozilla/rust/src/librustc/lib.rs -Z no-trans
	time_unit: i
	#-----------
	snapshot=0
	#-----------
	time=0
	mem_heap_B=0
	mem_heap_extra_B=0
	mem_stacks_B=0

	#![recursion_limit = "300000"]

	type CellType = u8;
	const MEM_SIZE: usize = 30_000;

	macro_rules! Hodor_impl {
	/*

	# Loop Extraction