Is it possible to avoid the GC for delegates? - d

Question

Is it possible to avoid the GC for delegates?
I am building a task system. I have N-Threads with a local task queue. A task queue is basically just a Array!Fiber tasks. Because it is discouraged to send fibers to a different thread, I am sending a closure/delegate to a thread, create the fiber from that delegate and put it in the array tasks.
Now the delegates that I am sending are delegates that capture variables.
//Some Pseudo code
auto f = //some function;
auto cell = Cell(...);
auto del = () {
let res = f();
cell.write(res);
}
send(del);
}
Now cell is heap allocated and synchronized with an atomic counter. I can then check if the atomic counter from cell has reached 0, if it did I can safely read from it.
The problem is that delegates which capture variables, allocate the variables on the GC. Now I only allocate a pointer and it is probably not a huge problem but I would still like to avoid the GC.
How would I do this?

Answer 1

You might already know all this, but this is a bit of a FAQ so I'm going to write a few details.
First, let's understand what a delegate is. Like how a slice is just a C data pointer paired with a length, a delegate is just a C data pointer paired with a function pointer. These are passed together to functions expecting them, as if it was defined
struct d_delegate {
void* ptr; // yes, it is actually typed void*!
T* funcptr; // this is actually a function pointer
};
(Note that the fact that there is just one data ptr in there is the reason behind some compiler errors when you try to take a nested delegate inside a class method!)
That void* is what points to the data and like with a slice, it can come from a variety of places:
Object obj = new Object();
string delegate() dg = &obj.toString;
At this point, dg.ptr points to obj, which happens to be a garbage collected class object, but only because I newed it above.
struct MyStruct {
string doSomething() { return "hi"; }
}
MyStruct obj;
string delegate() dg = &obj.doSomething;
In this case, obj lives on the stack due to how I allocated it above, so the dg.ptr also points to that temporary object.
Whether something is a delegate or not says nothing about the memory allocation scheme used for it - this is arguably dangerous because a passed delegate to you might point to a temporary object that will disappear before you're finished with it! (That's the main reason why GC is used by the way, to help prevent such use-after-free bugs.)
So, if delegates can come from any object, why are they assumed to be GC so much? Well, the automatically generated closure can copy local variables to a GC segment when the compiler thinks the lifetime of the delegate is longer than the outer function.
void some_function(void delegate() dg);
void foo() {
int a;
void nested() {
a++;
}
some_function(&nested);
}
Here, the compiler will copy the variable a to a GC segment because it assumes some_function will keep a copy of it and wants to prevent use-after-free bugs (which are a pain to debug as it frequently leads to memory corruption!) as well as memory leaks.
However, if you promise the compiler that you'll do it right yourself by using the scope keyword on the delegate definition, it will trust you and leave the locals right where they are:
void some_function(scope void delegate() dg);
Keeping the rest the same, it will no longer allocate a copy. Doing it on the function definition side is the best because then you, as the function author, can ensure you don't actually keep a copy.
On the usage side though, you can also label it scope:
void foo() {
int a;
void nested() {
a++;
}
// this shouldn't allocate either
scope void delegate() dg = &nested;
some_function(&dg);
}
So, the only time memory is automatically allocated by the GC is when local variables are used by a nested function which has its address taken without the scope keyword.
Note that the () => whatever and () { return foo; } syntaxes are just shorthand for a named nested function with its address being automatically taken, so they work the same way as the above. dg = {a++;}; is the same as dg = &nested; above.
Thus, the key takeaway from this for you is that if you want to manually allocate a delegate, you just need to manually allocate an object and make a delegate from one of its methods instead of automatically capturing variables! But, you need to keep track of the lifetime and free it properly. That's the tricky part.
So for your example:
auto del = () {
let res = f();
cell.write(res);
};
you might translate that into:
struct Helper {
T res;
void del() {
cell.write(res);
}
}
Helper* helper = malloc(Helper.sizeof);
helper.res = res; // copy the local explicitly
send(&helper.del);
Then, on the receiving side, don't forget to free(dg.ptr); when you're done so you don't leak it.
Or, better yet, if you can change send to just actually take Helper objects, you don't need to allocate it at all, you can just pass it by value.
It also occurs to me that you could pack some other data in that pointer to pass other data in-place, but that'd be abi hacking and possibly undefined behavior. Try it if you wanna play though :)