Possible design for alias counting

[sophiajt]

(Inspired from brainstorming with Mae Milano and @yaahc)

Untracked:

class Node {
  next: Node?
}

owned class Foo {
  node: Node?
}

Tracked

class Node {
  next: Node?
}

owned tracked class Foo {
  node: Node?
}

By marking an owned class as tracked, the pointers within it are granted an alias count (similar to a refcount). As we know these aliases do not escape from the class Foo because ownership implies that all shared pointers it references are completely dominated/encapsulated by it, it's safe to augment the reading from and writing to these pointers.

Open questions:

• Where are the counts kept? If we keep them on the owned class, we'll need an efficient way to do so that doesn't require a lookup. If instead they are on the encapsulated pointer's representation, then we'll need to be able to augment the representation in a safe way.
  • The only way I can think to do this safely is to pack the alias count alongside the allocation group id, and require that if you are tracking a type, it needs to be a type with a hidden allocation group field
• Are we going to require owned on the definition for owned structs to ensure that it's clear that tracking only happens on owned types?
• What's a good keyword? tracked feels like Foo is tracked, but instead it's the dominator of tracked pointers
• Do we want to blanket track all fields? Or should we mark fields as tracked explicitly rather than the whole definition

Exploring what that might look like:

class Node {
  next: Node?
}

owned class Foo {
  tracked node: Node?
}

[sophiajt]

Current thoughts:

owned on the class is where we put the indicator of when we want something tracked. This will give it its own allocator pages in the group that only it controls, and allocations to these pages create bi-pointers. The header of the bi-pointer will keep the alias count, while the remainder is the original constructed state.

All pointers created inside of the owned are encapsulated and dominated by the owned pointer and fall into the same special allocator pages, so the allocations they create will also be bi-pointers.