Re: concurrent garbage collection and POSIX threads

"Boehm, Hans" <[email protected]> Mon, 11 Jan 2010 22:59:44 +0000
Newsgroups gmane.comp.programming.garbage-collection.general
Message-ID <238A96A773B3934685A7269CC8A8D0425782E2B623@GVW0436EXB.americas.hpqcorp.net>
[A bit of an aside:]

> From:  Mingnan Guo
> Also, should keep in mind that,=20
>=20
> ...=20
>=20
> (2) Usually, threads' execution stacks are treated by threads=20
> as _Thread_Private_Data_, not as shared with other threads as=20
> objects in heap. So when GC determines root set, it is=20
> accessing other threads' _Thread_Private_Data_.
>=20
This actually seems to be a fairly fundamental difference between Java and =
common C/C++ usage.  In C or C++, something like the following seems fairly=
 common:

t f()
{
    tt my_array[...];

    ...
    foo(my_array, ...);
}

where foo() itself processes different sections of the array in parallel.  =
Think of foo() as a parallel sort. (In C++, watch out for exceptions thrown=
 from inside foo() that fail to terminate the other threads!)  Thus data li=
ke my_array is on the thread stack, but definitely not thread-private.  In =
slight variations of this, the function f() may itself may end up processin=
g parts of the array in parallel with foo().

You can't write such code in Java.  I claim you can't really do without it =
in C or C++, since f() shouldn't have to know whether foo() uses more than =
one thread.  ("C++0x" requires this to work, C1x does not.  I suspect that =
C1x implementations that don't support this won't be widely used.)

Hans=