On 17-10-2012 11:50, sclytrack wrote:
On Wednesday, 17 October 2012 at 08:55:55 UTC, Alex Rønne Petersen wrote:
On 17-10-2012 10:29, renoX wrote:
Hello,
in the discussions thread in the recent blog post which summarized how
GC works(*), the topic of thread-local GC was further discussed and I
pointed out that by default global variables in D are thread local but I
was answered that the types doesn't tell which global variable are
thread local and which are shared so the GC cannot use this information,
is-it true?
It seems like a wasted opportunity..
BR,
renoX
*:
http://xtzgzorex.wordpress.com/2012/10/11/demystifying-garbage-collectors/
Let's step back for a bit and think about what we want to achieve with
thread-local garbage collection. The idea is that we look only at a
single thread's heap (and stack/registers, of course) when doing a
collection. This means that we can -- theoretically -- stop only one
thread at a time and only when it needs to be stopped. This is clearly
a huge win in scalability and raw speed. With a scheme like this, it
might even be possible to get away with a simple mark-sweep or copying
GC per thread instead of a complicated generational GC, mainly due to
the paradigms the isolation model induces.
Rust, as it is today, can do this. Tasks (or threads if you will -
though they aren't the same thing) are completely isolated. Types that
can potentially contain pointers into a task's heap cannot be sent to
other tasks at all. Rust also does not have global variables.
So, let's look at D:
1. We have global variables.
1. Only std.concurrency enforces isolation at a type system level;
it's not built into the language, so the GC cannot make assumptions.
1. The shared qualifier effectively allows pointers from one thread's
heap into another's.
It's important to keep in mind that in order for thread-local GC (as
defined above) to be possible at all, *under no circumstances
whatsoever must there be a pointer in one thread's heap into another
thread's heap, ever*. If this happens and you apply the above GC
strategy (stop one thread at a time and scan only that thread's heap),
you're effectively dealing with something very similar to the lost
object problem on concurrent GC.
To clarify with regards to the shared qualifier: It does absolutely
nothing. It's useless. All it does is slap a pretty "I can be shared
arbitrarily across threads" label on a type. Even if you have this
knowledge in the GC, it's not going to help you, because you *still*
have to deal with the problem that arbitrary pointers can be floating
around in arbitrary threads.
(And don't even get me started on the lack of clear semantics (and
even the few semi-agreed-upon but flawed semantics) for shared.)
Introduce the "noshared" keyword.
Not a practical solution.
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
