[D-runtime] Precise garbage collection

Steven Schveighoffer schveiguy at yahoo.com
Fri Jun 28 21:33:19 PDT 2013


On Jun 28, 2013, at 5:28 PM, Rainer Schuetze <r.sagitario at gmx.de> wrote:

> On 28.06.2013 16:16, Steven Schveighoffer wrote:
>> Another consideration to think about -- we currently have no calls
>> to non-class finalizers in the GC.  Using TypeInfo pointers would
>> facilitate this.
> 
> I think that could also be implemented by wrapping struct types with
> destructor in a class that contains the struct. That would go in
> _d_newitem* or _d_newarray*. Creating the appropriate type info at
> runtime might be a problem though.

Wrapping in a class may work, but seems heavyweight for just storing a finalizer pointer. 

> 
>> I feel like this may tip the scales towards an all-TypeInfo
>> solution.
> 
> There is still the problem of manually arranged data to be solved. E.g. the associative array combine node-list entry, key and value into a single allocation, and only the single type infos are available (if at all). Same problem as above: how to create a combined type info at runtime?

If you are inventing the type of the block, you are responsible for it.  Allocate it as a void * and you get to own how it works.  Otherwise, use a struct and let the system generate a type info for it.

The associative array could just as easily make a struct out of that pair.  It so happens that when AA's were written, they were a purely runtime feature, and did not have the ability to "invent" typeinfo.  The situation has changed -- AAs are now a template.

> The current implementation "emplaces" the pointer bits at the corresponding addresses, but this needs two additional calls into the GC, resulting in far from optimal performance.

You mean the current implementation of the precise GC or the AA?

BTW, I want to stress again that we really should attempt to move the compiler away from calling runtime functions, and instead have it call template functions.  Such things will make life SOOO much easier for experimentation, inlining runtime calls, etc.  For example, having the rtInfo has opened several doors already that weren't already envisioned on its creation.  Imagine if all runtime calls were wrapped in a template, and one could simply update the template to experiment with new ideas, instead of hooking the runtime function, which is limited to whatever was expected when written.

If this is the case, then instead of _d_newarray struggling to create a dummy typeinfo so a dtor is called (I have actually done this before in a project on D1, and it isn't pretty), a template can trivially generate the class.

-Steve


More information about the D-runtime mailing list