Reddit: http://www.reddit.com/r/programming/comments/1fpw2r/dconf_2013_day_2_talk_5_a_precise_garbage/

Hackernews: https://news.ycombinator.com/item?id=5825320

Twitter: https://twitter.com/D_Programming/status/342269600689430529

Facebook: https://www.facebook.com/dlang.org/posts/651801198166898

Youtube: http://youtube.com/watch?v=LQY1m_eT37c

Please drive discussions on the social channels, they help D a lot.


Andrei

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

Bye,
bearophile

On Wednesday, 5 June 2013 at 14:14:45 UTC, 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
>
> Bye,
> bearophile

Here is the blog post deadalnix is referring about at the very end of the video:
http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using-non-precise-gc/

SomeDude:

>> 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
>>
>> Bye,
>> bearophile
>
> Here is the blog post deadalnix is referring about at the very end of the video:
> http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using-non-precise-gc/

I don't understand how your answer is related to my question...

Bye,
bearophile

On Wednesday, 5 June 2013 at 20:14:32 UTC, bearophile wrote:
> I don't understand how your answer is related to my question...

At least in terms of memory leaks, preciseness is solving a problem that doesn't exist on 64 bit. I don't know if precise stack scanning does anything on 32 bit though and idk about the gc's speed difference in any case.

On Wed, 05 Jun 2013 09:23:30 -0400
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Reddit: http://www.reddit.com/r/programming/comments/1fpw2r/dconf_2013_day_2_talk_5_a_precise_garbage/
> 

Torrents up, and the other links: http://semitwist.com/download/misc/dconf2013/

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.

As parameters to function are covered by the callee, the approach won't work if you pass a temporary reference to a C function, which does a callback into code that has a safe point. The temporary on the stack will not be seen during a collection. Example:

/// D
void main() { c_func(toStringz(to!string(3))); }
bool gc_running() { gc_check(); return true; }

/// C
void c_func(const char* s) { if(gc_running()) printf("s=%s\n", s); }

My idea is to generate a description of the stack with information where pointers might be found within the functions stack space. If this includes parameters to called functions you might not even have problems with pausing a thread inside a C callback. This is slightly less precise because some stack fields might be used by both pointers and non-pointers. The runtime overhead would be similar to the implementation in the paper: insert/remove descriptors from a single linked list.

On Wednesday, 5 June 2013 at 13:23:30 UTC, Andrei Alexandrescu wrote:
> Reddit: http://www.reddit.com/r/programming/comments/1fpw2r/dconf_2013_day_2_talk_5_a_precise_garbage/
>
> Hackernews: https://news.ycombinator.com/item?id=5825320
>
> Twitter: https://twitter.com/D_Programming/status/342269600689430529
>
> Facebook: https://www.facebook.com/dlang.org/posts/651801198166898
>
> Youtube: http://youtube.com/watch?v=LQY1m_eT37c
>
> Please drive discussions on the social channels, they help D a lot.
>
>
> Andrei

Very cool presentation.
Thank you Rainer.

Interesting talk. It seems there are a few features D could provide which would make for some more powerful GCs:

- Hook for when generating code which reads/writes a pointer allowing GC to put in read/write barriers where necessary.

- Hook for union assignment so that the GC could emplace the correct type bits

- Hook for passing pointers to extern(XXX) functions so that the GC can pin the arguments allowing a compacting GC

- Hook for function call/return so that stack type-info can be stored. There's actually another way to do this which would have less overhead - at compile time the compiler could write the address range of each function along with a bitmap for possible pointers in that function to some known location. When the GC runs it could unwind the stack and look each frame pointer up in the list of functions to find the bit pattern to use. When calling a function that does some low-level stuff and might prevent the unwinding from working correctly it would be possible to switch back to conservative mode until the function returns.

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.

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

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.

Kind Regards
Benjamin Thaut