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

[Benjamin Thaut]

Am 08.06.2013 09:50, schrieb 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?

Not for every pointer assignment, only for pointers that are on the 
heap. Also most of these write barries could be skipped with really 
cheap tests most of the time.

>
>>
>> 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.

Good point, didn't think about that yet. In Order to improve the 
performance of the GC we have to sacrifice performance in other places 
of the language in my opinion. Given the fact that the current GC is 3 
times slower then manual memory mangement (in my test case). It should 
be easly possible to take a performance hit here and there but end up 
beeing faster in the end anyway. The current GC is especially bad with 
short lived allocations and I don't think this is going to get any 
better when only using a Mark & Sweep. The D community has to see that 
to get a state of the art GC some perfomance sacrifces have to be done. 
If those are not wanted we can go back to manual memory management right 
away, in my opinion. I recently also had a long talk with Claus 
Gittinger (created the SmalltalkX VM) about the topic. He also had the 
same opinion on the topic. He also stated that it is going to be very 
hard if not impossible to implement a state of the Art GC into a 
language like D which does not have any restrictions in the language 
which help with that Task.

>
>>
>> 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.

No one said that it is a simplification. Its always going to get more 
complicated if you want a better GC.

>
> 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.

Then maybe the semantics of shared should be defined with a GC in mind.