Componentizing D's garbage collector

[evansl]

On 01/15/14 02:54, Rainer Schuetze wrote:
> On Monday, 13 January 2014 at 22:48:37 UTC, evansl wrote:
>> On 01/11/14 03:30, Rainer Schuetze wrote:
>>>
>>>
>>> On 10.01.2014 22:42, Andrei Alexandrescu wrote:
>> [snip]
>>>> std.emplace will continue to work as a way to build an object at a
>>>> specified address. I suspect that allocating and manipulating
>>>> objects on
>>>> the GC heap in particular may have certain restrictions. One
>>>> possibility
>>>> to avoid such restrictions is to have a function typify(T)(void* p)
>>>> which ascribes type T to heap location p.
>>>
>>> That sounds similar to my gc_emplace function. The problematic part is
>>> how to save that information in the GC.
>>>
>> [snip]
>> Couldn't you store a pointer to the typeinfo within the
>> allocated memory? IOW, the first part of the allocated memory
>> would be the typeinfo* followed by the actual memory used to store the
>> value of the allocated T object.
>>
>> -regards,
>> Larry
>
> std.emplace can be used on a partial memory block (e.g. as part
> of a struct), so you will have to add the emplaced type info in
> addition to the outer struct's type info. There can be multiple
> areas with emplaced dta within the same memory allocation, too.
> So you'll need to store a list of type infos paired with the
> offsets within the meory block. How do you do this efficiently
> without extra cost for the usual scanning?

I'm afraid I'm not familiar with much of what you're talking about.
However, in another thread, containing this post:

http://forum.dlang.org/post/ldhquc$11ec$1@digitalmars.com

Benjamin mentioned RTInfo*.  Which made me think that instead of
pointer to the typeinfo, what about a RTInfo pointer which, according
to comments at:

https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/object_.d#L1101

is the data for precise GC.  Surely if RTInfo contains the data for
precise GC, then that would work.  However, I'm guessing that RTInfo*
is only available for class types.  OTOH, couldn't the compiler figure
out the similar information for struct types?  Then, if a class type
were being scanned, use the existing RTInfo* in the object supertype.
OTOH, if a struct type type is being scanned, then use the compiler
generated RTInfo for the struct type, a pointer to which could be
placed in the heap memory just before the memory for the struct.  I
guess the scanner would then have to be able to figure out if a void*
was pointing to a struct or a class and behave accordingly.

Of course I'm probably missing something, coming from a c++
background; hence, I'd appreciate someone pointing out what I'm
missing.

-regards,
Larry