www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - closure vars typeinfo

reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Jun 11 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jun 12 2013
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Jun 12 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Jun 12 2013
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Jun 12 2013