Re: DConf 2013 Day 2 Talk 5: A Precise Garbage Collector for D by Rainer Schütze

[Rainer Schuetze]

On 06.06.2013 22:27, Benjamin Thaut wrote:
> Am 06.06.2013 08:28, schrieb Rainer Schuetze:
>>
>>
>> On 05.06.2013 16:14, bearophile wrote:
>>> Andrei Alexandrescu:
>>>
>>>> http://www.reddit.com/r/programming/comments/1fpw2r/dconf_2013_day_2_talk_5_a_precise_garbage/
>>>>
>>>>
>>>>
>>>
>>> Is this useful to make the GC precise regarding the stack too?
>>>
>>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.5570
>>
>> I was imagining something similar too. The part about multi-threading in
>> the paper isn't too convincing, though. Especially the need for GC safe
>> points in tight loops to block a thread during collection will not get
>> many friends in the D community.
>>
>
> I think you don't really need percise scanning which is thread safe. If
> you have one pool per thread, and you can scan the thread local pools
> percisley within the thread that would be enough. Because you would then
> be able to do generational garbage collection for the thread local
> pools. If you have to scan one of (or the) global pool, percise scanning
> of the stacks is not really needed, the old impercises scanning is
> sufficient, you just have to pin those memory blocks you might think are
> referenced from stack memory.

Wouldn't that mean a write-barrier for every pointer assignment?

>
> But to be able to actually do thread local pools a bit more then write
> barriers would be needed. For each of the following situations a call
> into druntime would be needed.
>
> 1) Creating a shared or immutable object
> 2) Casting to shared or immutable
> 3) Assigning a shared, immutable, __gshared global or static variable

Considering "string" is "immutable(char)[]", would you want to allocate 
all temporary strings on the global heap? Also, I don't like to have 
possible expensive operations for casting.

>
> If you have these and you are able to percisley scan the stack for the
> current thread only you will then be able to move all of the referenced
> memory from the thread local pool to the global pool if any of the above
> calls happen.
>
> This would mean that most of the time only thread local garbage
> collection would be neccessary and you won't have to stop other threads
> from doing whatever they are doing. Only in rare cases it should be
> necessary to scan the global pool.

I agree that a thread local pool can give good performance improvements. 
But as long as you still have a global heap (which you probably cannot 
eliminate), it's not a simplification to have thread local garbage 
collections in addition.

The problem to implement it is that shared semantics are still pretty 
undefined. AFAICT "shared" is only a type modifier that has different 
conversion rules than non-shared types. There are no runtime guarantees 
with "shared", even less with the absence of shared, and even if they 
exist, __gshared and casting are meant to subvert them.