6.4 Migrating away from the GC heap
How does a programmer know which objects should be allocated on the manual heap? Our methodology is
to use a heap proling tool (e.g. we have modied PerfView, a publicly available tool from Microsoft), to
determine if the GC has a signicant cost, then identify objects of reasonable size that have survived and
have been collected in the older generations, get the stack traces associated with such objects and look for
sensible candidates amongst those with clearly dened lifetimes.

6.5 Programming model
By-ref style of owners and shields Owners and shields cannot be duplicated on the stack or returned
from arbitrary functions, and hence can only be passed \by-ref", complicating the porting of an application.
For some applications this is not a problem (e.g. System.Linq.Manual) but for others it may require redesign
of APIs and implementation.
Sharing references on the heap A well known limitation of owner-style objects (and unique references
in general) is that sharing of multiple references to the same manual object from the (GC or manual) heap is
not allowed, thus making them unsuitable for data structures with a lot of pointer sharing. Snow
ake allows
shareable pointers to be built around owners. For instance, we have introduced a class called Manual<T>
(as opposed to a struct), that encapsulates an Owner<T> and supports similar methods but can be stored on
the heap and passed to or returned by other functions like every other GC object. In exchange for greater
programming
exibility, object Manual<T> incurs extra space cost per manual object, so calls for a careful
prole-driven use. Finally, we have also built shareable reference counted objects, RefCount<T>, but we are
considering API extensions in this space as important future work.
Shields on the heap Shields may accidentally escape on the (shared) heap, resulting in complaints in
our C# frontend, predominantly due to the subtle C# implicit boxing feature or closure capture. For other
examples, we may actually prefer to temporarily store a shield on the heap, as long as we can guarantee
that only the very same thread that created that shield will access it and the underlying object (otherwise
the reference to the TLS state is bogus). How to enable this without sacricing performance is an open
challenging problem.
Finalization and owners When owner objects get abandoned our runtime abandons recursively their
children owner elds. To do this eciently we extend the method table with an explicit run-length encoding
of the osets that the owner elds exist in an object and use that to eciently scan and abandon. An avenue
for future work is to modify the layout of objects to group together owner elds to improve this scanning,
similarly to what CoreCLR is using for GC pointers. .NET also allows for nalizers, which are functions that
can be called from a separate thread when objects are no longer live. There is design space to be explored
around nalizers for manual objects, e.g. should they be executed by the mutator or scheduled on the GC
nalization thread.
Asynchronous tasks In the async and await [2] popular C# programming model a thread may produce
a value and yield to the scheduler by enqueuing its continuation for later execution. This continuation may
be eventuall executed on a dierent thread. This decoupling of tasks from threads makes the use of the
thread-local shields challenging and it is an open problem of how to allow a task that resumes on a dierent
thread to safely use a shield.