[D-runtime] Precise garbage collection

[Rainer Schuetze]

On 08.08.2013 20:06, Michel Fortin wrote:
> Le 8-août-2013 à 0:54, Rainer Schuetze <r.sagitario at gmx.de> a écrit
> :
>
>> On 08.08.2013 03:05, Michel Fortin wrote:
>>> Funny problem. But there's no ambiguity really because you can't
>>> create using "new" a memory block that'll only contain a
>>> reference to an object. You can thus be sure that if the root
>>> type of a memory block is a TypeInfo_Class it truly is an object
>>> of that class; and if a*variable*  has TypeInfo_Class then it's a
>>> reference.
>>
>> That's what my code currently assumes. But that doesn't work if
>> std.emplace is used to create a class instance into the memory of a
>> struct instance. How can you distinguish that the memory is used as
>> a reference or an instance of that class.
>
> More importantly, how would emplace signal the GC that it is
> instantiating an object of a certain type in "void[]" memory in the
> first place? For all you know, with emplace one could construct and
> destruct and reconstruct objects of different classes, or things
> other than classes, in the same block of memory. If emplace is
> calling a specific function to add a root of a certain type, you can
> create a special flag or separate function for "in-place objects" and
> make emplace call this function.

That's what the new gc_emplace(void*p,size_t len,TypeInfo ti) function 
in the precise gc implementation is meant for.

>
>> The same happens with classes generated into the data segment by
>> the compiler, e.g. TypeInfo_Class objects. These currently don't
>> have mutable references that could point into GC allocated memory,
>> but a recent change also allows creating user defined class
>> instances to be built into the data segment.
>
> I can't really comment on this because I have no idea how you're
> getting any typeinfo for the data segment.
>

I have patched the compiler to emit this information. Without it false 
pointers in the data segment ruin all the efforts for the heap, because 
there is even no NO_SCAN flag for GUIDs, unicode encoding tables, 
strings, etc. (See also the dconf talk/slides) I intended to discuss it 
in a second step.