I'm catching up on the dconf videos tonight and just watched the precise garbage collector one, where he said there's no info for closures. Would it work if the closure's void* went to something along these lines?

struct Closure {
    // magic a magic number to help identify this block

    size_t number_of_variables_captured;
    TypeInfo[number_of_vars_captured] capturedVarTypes;

    // whatever else is needed

    ubyte[xx] capturedVars;
}

The gc could read this and it might be useful for debugging too.

But I'm mostly just wondering if you guys thought any more about how to (or if you want to) tackle this at the conference.

On 06/12/2013 02:08 AM, Adam D. Ruppe wrote:
> I'm catching up on the dconf videos tonight and just watched the precise
> garbage collector one, where he said there's no info for closures. Would
> it work if the closure's void* went to something along these lines?
>
> struct Closure {
>      // magic a magic number to help identify this block
>
>      size_t number_of_variables_captured;
>      TypeInfo[number_of_vars_captured] capturedVarTypes;
>
>      // whatever else is needed
>
>      ubyte[xx] capturedVars;
> }
>
> The gc could read this and it might be useful for debugging too.
>
> But I'm mostly just wondering if you guys thought any more about how to
> (or if you want to) tackle this at the conference.

The info shouldn't be stored inline, since it is shared by all closures created at the same site.

On 12.06.2013 02:08, Adam D. Ruppe wrote:
> I'm catching up on the dconf videos tonight and just watched the precise
> garbage collector one, where he said there's no info for closures. Would
> it work if the closure's void* went to something along these lines?
>
> struct Closure {
>      // magic a magic number to help identify this block
>
>      size_t number_of_variables_captured;
>      TypeInfo[number_of_vars_captured] capturedVarTypes;
>
>      // whatever else is needed
>
>      ubyte[xx] capturedVars;
> }
>
> The gc could read this and it might be useful for debugging too.
>
> But I'm mostly just wondering if you guys thought any more about how to
> (or if you want to) tackle this at the conference.

I was considering a struct that has the exact memory layout of the allocated closure. When allocating it the type info of this struct can be passes to the GC.

Example:

auto fun()
{
	int x = 3;
	int *y = &x;
	return () { return x + *y };
}
auto dg = fun();

Assuming it is not optimized away, the allocated closure would be identical to

struct fun_anonymous_closure
{
	int x;
	int* y;
}

and typeid(fun_anonymous_closure) can be passed to the GC to describe the allocated memory.

The debug info for the struct would probably immediately work for watching "x" and "y" in a debugger as the context pointer is usually called "this" inside the delegate.

On 6/12/2013 1:48 PM, Rainer Schuetze wrote:
> The debug info for the struct would probably immediately work for watching "x"
> and "y" in a debugger as the context pointer is usually called "this" inside the
> delegate.

It's probably a good idea to do that, but it isn't urgent.

On Wednesday, 12 June 2013 at 20:48:12 UTC, Rainer Schuetze wrote:
> and typeid(fun_anonymous_closure) can be passed to the GC to describe the allocated memory.

Thar sounds pretty good, and I can use it in my gc-less thing too.