Re: concurrent garbage collection and POSIX threads

I am sorry you misunderstood what I said.

I said: "... collector can run as a lowest priority thread ...".

It is just the opposite to your presumption. In HnxGC, collector thread can=
 be set to run at the *LOWEST* level (equal or close to idle, not HIGHEST a=
s you presume). So, all other threads can preempt GC thread at any time by =
OS scheduler, and collect only get chance to run when OS scheduler pass con=
trol to it, such as when all other tasks are finished or blocked(pending/wa=
iting for I/O, etc.)

- Mingnan Guo

--- On Fri, 1/8/10, Boehm, Hans <[email protected]> wrote:

> From: Boehm, Hans <[email protected]>
> Subject: Re: [gclist] concurrent garbage collection and POSIX threads
> To: "leland" <[email protected]>, "Rafael R. Sevilla" <dido@imperium=
.ph>
> Cc: "[email protected]" <[email protected]>
> Received: Friday, January 8, 2010, 1:28 PM
> > From: leland
> > Sent: Friday, January 08, 2010 12:15 PM
> > --- On Tue, 1/5/10, Rafael R. Sevilla <[email protected]>
> wrote:
> >=20
> > > From: Rafael R. Sevilla <[email protected]>
> > > Subject: [gclist] concurrent garbage collection
> and POSIX threads
> > > To: [email protected]
> > > Received: Tuesday, January 5, 2010, 10:14
> PM=C2=A0 I'm attempting to=20
> > >implement a=C2=A0 concurrent garbage collector
> (specifically=C2=A0 the=20
> > >Huelsbergen-Winterbottom VCGC algorithm) for a
> small=C2=A0 compiled=C2=A0=20
> > >language I'm working on and they it requires that
> one be=C2=A0=20
> > able to pause=C2=A0=20
> > >execution of all running threads during a
> barrier=C2=A0 synchronization=20
> > >event=C2=A0 at the end of a garbage collection
> epoch, and then resume=C2=A0=20
> > >execution of=C2=A0 these threads afterwards.=C2=A0 I
> believe many other=C2=A0=20
> > >concurrent garbage=C2=A0 collection algorithms
> have similar=20
> > requirements.=C2=A0=20
> > >How=C2=A0 would one=C2=A0 implement this using
> POSIX.1b/1c primitives alone?
> > > The pause and resume
> > >=C2=A0 are in general asynchronous.=C2=A0 I've thought up
> a=C2=A0 rather=20
> > convoluted=C2=A0=20
> > >method that involves adding a signal handler for
> each=C2=A0 thread, which=20
> > >upon=C2=A0 receipt of a POSIX real time signal,
> does a wait on a=C2=A0=20
> > condition=C2=A0=20
> > >variable.=C2=A0 When the thread is to be resumed,
> the=C2=A0 condition=20
> > variable is=C2=A0=20
> > >signaled, causing all threads waiting on it to
> resume=C2=A0=20
> > execution, at=C2=A0=20
> > >which point the signal handler returns and
> execution=C2=A0 resumes.
> > >=20
> > > I wonder if there is an easier way to do this
> that does not require=20
> > > these kinds of contortions.=C2=A0=C2=A0=C2=A0There are=20
> > thr_suspend/thr_resume calls=20
> > > in Solaris, and in older versions of Linux using
>=20
> > LinuxThreads it was=20
> > > possible to use SIGSTOP/SIGCONT on the thread ID,
> but with=20
> > NPTL, which=20
> > > is now fully POSIX-compliant, the use of those
> signal would=20
> > stop all=20
> > > threads, which I do not want.=C2=A0 Any hints from
> those who have=20
> > > implemented such garbage collectors?
> > >=20
> > > --=20
> > >
> =E5=AD=98=E5=9C=A8=E3=81=99=E3=82=8B=E3=81=A8=E3=81=84=E3=81=86=E3=81=93=
=E3=81=A8=E3=81=AF=E3=80=81=E8=87=AA=E5=88=86=E3=82=92=E5=89=B5=E9=80=A0=E3=
=81=99=E3=82=8B=E3=81=93=E3=81=A8=E3=81=A0=E3=80=82
> > > http://stormwyrm.blogspot.com

> > >=20
> > >
> >=20
> > You don't have to pause any execution of app threads
> for a=20
> > concurrent garbage collector. A full concurrent
> garbage=20
> > collector can run as a lowest priority thread, and
> never=20
> > invoke any thr_suspend/resume the like calls.
> >=20
> I don't understand.=C2=A0 Presumably you want the GC to run
> at the HIGHEST priority, so that it can't be
> interrupted?=C2=A0 Even then, this makes several
> assumptions, which are dubious in my environment:
>=20
> 1) You need as many GC threads as physical
> processors.=C2=A0 This seems very unfriendly to other
> processes on the system, unless you assume a
> uniprocessor.=C2=A0 You're basically taking control of the
> whole machine, not just process.
>=20
> 2) Everyone needs to use a scheduling policy that strictly
> respects priorities.=C2=A0 I think that most modern systems
> support that, but it's generally not the default.=C2=A0
> Linux seems to require root privileges for it, since it
> allows you to take control of the whole machine.=C2=A0 In my
> experience, you want to avoid strict priorities whenver you
> can, since they introduce way too many interesting live-lock
> possibilities.
>=20
> 3) No other threads decide to run at the highest
> priority.=C2=A0 (This one is probably OK in many
> environments.)
>=20
> 4) You can retrieve the thread states without cooperation
> of the affected threads.=C2=A0 This is probably possible
> using debug interfaces, but tricky.
>=20
> This sounds like an approach that might work in some
> real-time environments, but not generally.
>=20
> Hans