On Saturday, 25 June 2016 at 11:37:44 UTC, rikki cattermole wrote:
I've thought about this further, the only hook function we
don't currently have is related to global + TLS assignment for
memory.
We can get away with e.g. new overriding and ~ via the GC proxy
(actually a fairly decent way to go about it).
Since this assignment hook is potentially quite expensive, it
definitely should be only if used under whatever attribute we
use.
I think the basic idea would be that the fiber heap is presumed
to work like a region allocator that is never collected, except
when you run low on memory, then you scan only the fiber-local
memory (and since it is local you could possibly also compact).
So:
1. References to the fiber heap can only be made from the same
fiber heap or the fiber stack.
2. You can hand out borrowed fiber-references to the fiber heap
when calling non-fiber functions, but fiber-references can never
be turned into non-fiber references.
3. Aggregates (structs/classes/arrays) that can contain
fiber-references are tainted as fiber-local and cannot leave the
fiber.
Then you need a mechanism that transitively converts fiber-local
data into non-fiber-local data. This can be done as either:
1. Deep copy.
2. Traverse-and-pin-memory-as-exported, then reinterpret cast
into non-fiber-local types.
3. Optimization: a priori detected as non-fiber-local using
static analysis and allocated in a separate heap and then
reinterpret casted into non-fiber-local before being exported
outside the fiber.
Memory outside the fiber can use regular reference-counting.
Of course, this could also be generalized to something that would
not only work for fibers, but also for stack-less contexts such
as a facade to a global graph that is only collectible at
specific points in the code. So you collect only where there are
no external references to internal nodes (or use
reference-counted pinning for exports).
A fiber-local heap would be a special case where the fiber-stack
is part of the fiber-local heap.
I think this might work. The assumption is that GC is most useful
in a singular execution context and that more manual management
(like reference counting) is acceptable between execution
contexts.
