(Semi) precise GC [was: Re: Std Phobos 2 and logging library?]

[Robert Jacques]

On Tue, 14 Apr 2009 11:34:05 -0400, Frits van Bommel  
<fvbommel at remwovexcapss.nl> wrote:
> Robert Jacques wrote:
>> On Tue, 14 Apr 2009 09:27:09 -0400, Frits van Bommel  
>> <fvbommel at remwovexcapss.nl> wrote:
>>> Robert Jacques wrote:
>>>> On Tue, 14 Apr 2009 06:04:01 -0400, Frits van Bommel  
>>>> <fvbommel at remwovexcapss.nl> wrote:
>>>>> Using D2 structs with a moving GC would need some extra bookkeeping  
>>>>> data anyway, to work out things like their postblit call.
>>>>  Postblit is only called when generating an actual copy. For example  
>>>> it is not called on assignment is the source is no longer used. So I  
>>>> don't see any reason why it should, or it would be expected that  
>>>> postblit would run when a struct was moved using the GC.
>>>
>>> Oh, I didn't know that. (I haven't done much of anything with D2, I  
>>> mostly stick to D1)
>>> I just presumed they were like C++ copy constructors.
>>>
>>> As an aside: I can certainly think of some places where it would be  
>>> useful to have them get called whenever the address changes...
>>> (Though "move constructors" would be even better for most of those  
>>> cases)
>>  Could you document this use case? (i.e. give some examples as I can't  
>> think of any)
>
> Any situation in which structs register themselves somewhere for one  
> reason or another.
>
> For example, I read that C++'s shared_ptr<> could be implemented by  
> having the instances keep a doubly-linked list of themselves instead of  
> using an extra heap allocation for the reference count. Such an  
> implementation would need to update the pointers in neighboring nodes  
> when moved, or insert itself before or after the original when copied.

Umm... aren't stack values not guaranteed to be stable? (i.e. isn't this  
like play Russian roulette with your optimizer?)

> Note that shared_ptr<> is not only useful for memory resources, it could  
> also be used to e.g. keep a file handle or socket open until all users  
> are done with it (and not longer, as you might get with a GC'ed file  
> class).
> Of course, in this case the more traditional approach with a  
> heap-allocated reference (or even storing it in the Monitor structure  
> each object has a pointer to) would be just as viable.
> But you could also implement weak references in a similar way, to let  
> the GC find them in a linked list and allow them to be nulled when  
> referred-to objects get collected.

Not all moving GCs or copy GCs for that matter, move every single object  
all the time, so this hack doesn't work. On the other hand, GC-User cache  
interaction would be nice (i.e. telling the GC about user free-lists, etc)

> There are probably other use cases...

Well, these are a use cases for a language level move operator, as it  
would allow for slightly better performance than a copy and dtor pair in  
some cases. (Sorry, I was thinking only about moving GCs when I posted,  
for which these aren't use cases)