Fiber local GC

[rikki cattermole via Digitalmars-d]

On 25/06/2016 11:55 PM, Ola Fosheim Grøstad wrote:
> 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.

This worries me.

1. This adds ref counting or some other form of restriction which has 
not been declared as to what it is.
2. Removes the ability to assign to globals limiting usage.

> 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.
>
>