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.
