Fiber local GC

[rikki cattermole via Digitalmars-d]

On 25/06/2016 10:33 PM, Ola Fosheim Grøstad wrote:
> Pony has a fiber local GC, which means collection can happen when the
> fiber is inactive  or even altogether skip collection if the fiber is
> short-lived.
>
> Go is currently exploring a Transaction Oriented GC addition to the
> concurrent GC it already has:
>
> https://docs.google.com/document/d/1gCsFxXamW8RRvOe5hECz98Ftk-tcRRJcDFANj2VwCB0/edit
>
>
> It takes the same viewpoint. A go-routine (fiber) that is short-lived
> (like a HTTP request handler) can release everything in one swipe
> without collection.
>
> I think this viewpoint is much more efficient and promising than D's
> thread-local viewpoint.
>
> What D needs is a type qualifier that keeps data "fiber local" and
> possibly a transition mechanism like Pony has for detecting objects that
> should be allocated on a global heap (or less efficiently, "pin objects"
> that are exported outside the fiber).

No need for a new keyword. What we could do is use a type like Vibe.d's 
TalkLocal to limit instances to the thread and register a context via a 
template for the struct describing the context.

struct MyContext {
	int x;
	string text;
}

TaskLocal!MyContext context;

shared static this() {
	registerFiberLocal(&context);
}

...

registerFiberLocal(T)(T* inst) if (is(T == struct)) { ... }

Hmm okay maybe not a good idea. As a library like this won't work.
What we want is to be able to explicitly say what the context is for a 
functions code and declare no globals.

@noglobals
struct MyContext {

	@disable
	this(this);	

	void func() {
		
	}
}

Function calls outside of the struct are ok for: @system, pure and 
@noglobals.
Making the struct pure wouldn't work since there goes @safe and @system 
calls.

MyContext.func would implicitly have @noglobals applied to it.

Now preferably we would have new hooks added so they could be in the 
context. Specifically if they are there they are used instead of the 
globals for e.g. GC. That way things like allocators could be used 
instead. Given that the context should be heap/stack allocated and never 
copied it would mean that once the fiber dies, all memory it uses is 
deallocated or returned to the pool.

Now I did say about hooks, there are no ways to do that without having a 
bunch of context pointers somewhere saying which function is currently 
set to the hook. If done via a stack it would given history for 
unsetting the current context allowing recursive.

The underlying fiber provider would have to inform the switch on e.g. 
yield. But that isn't hard to do.

Looking back perhaps we can allow globals, but we'd need to instead have 
a hook for when assigning to a global / passing to anything not pure 
that is heap based. That would allow "moving" memory ownership from the 
fiber to the process GC.


TLDR: I think we can do this with just a @noglobals attribute, but done 
properly it looks like we need proper hooks in place which are a lot harder.