Re: concurrent garbage collection and POSIX threads

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

> From: Hans Boehm <[email protected]>
> Subject: Re: [gclist] concurrent garbage collection and POSIX threads
> To: "leland" <[email protected]>
> Cc: "Boehm, Hans" <[email protected]>, "Rafael R. Sevilla" <dido@imperium=
.ph>, "[email protected]" <[email protected]>
> Received: Saturday, January 9, 2010, 12:14 AM
>=20
>=20
> On Sat, 9 Jan 2010, leland wrote:
>=20
> > 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=20
> > can be set to run at the *LOWEST* level (equal or
> close to idle, not=20
> > HIGHEST as you presume). So, all other threads can
> preempt GC thread at=20
> > any time by OS scheduler, and collect only get chance
> to run when OS=20
> > scheduler pass control to it, such as when all other
> tasks are finished=20
> > or blocked(pending/waiting for I/O, etc.)
> But then it sounds like the collector doesn't need to stop
> the client
> threads, since they can effectively continue to run while
> the collector
> is running?=A0
yes.=20

> That seems different from the orignal
> question?
Yes, it was a little bit off the topic. But I think=20
it might be useful to Rafael. It seems he is developing a=20
language, so he could design it to be friendly with GC and=20
generate client thread code cooperating with GC thread.=20
If so, it is not difficult to apply a full-concurrent GC=20
(such as HnxGC) to it.

- Mingnan Guo

>=20
> Hans
> >
> > - 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" <[email protected]>
> >> 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:
> >>>
> >>>> 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=A0 I'm attempting to
> >>>> implement a=A0 concurrent garbage
> collector
> >> (specifically=A0 the
> >>>> Huelsbergen-Winterbottom VCGC algorithm)
> for a
> >> small=A0 compiled=A0
> >>>> language I'm working on and they it
> requires that
> >> one be=A0
> >>> able to pause=A0
> >>>> execution of all running threads during a
> >> barrier=A0 synchronization
> >>>> event=A0 at the end of a garbage
> collection
> >> epoch, and then resume=A0
> >>>> execution of=A0 these threads afterwards.=A0
> I
> >> believe many other=A0
> >>>> concurrent garbage=A0 collection
> algorithms
> >> have similar
> >>> requirements.=A0
> >>>> How=A0 would one=A0 implement this using
> >> POSIX.1b/1c primitives alone?
> >>>> The pause and resume
> >>>> =A0 are in general asynchronous.=A0 I've
> thought up
> >> a=A0 rather
> >>> convoluted=A0
> >>>> method that involves adding a signal
> handler for
> >> each=A0 thread, which
> >>>> upon=A0 receipt of a POSIX real time
> signal,
> >> does a wait on a=A0
> >>> condition=A0
> >>>> variable.=A0 When the thread is to be
> resumed,
> >> the=A0 condition
> >>> variable is=A0
> >>>> signaled, causing all threads waiting on
> it to
> >> resume=A0
> >>> execution, at=A0
> >>>> which point the signal handler returns
> and
> >> execution=A0 resumes.
> >>>>
> >>>> I wonder if there is an easier way to do
> this
> >> that does not require
> >>>> these kinds of contortions.=A0=A0=A0There
> are
> >>> thr_suspend/thr_resume calls
> >>>> in Solaris, and in older versions of Linux
> using
> >>
> >>> LinuxThreads it was
> >>>> possible to use SIGSTOP/SIGCONT on the
> thread ID,
> >> but with
> >>> NPTL, which
> >>>> is now fully POSIX-compliant, the use of
> those
> >> signal would
> >>> stop all
> >>>> threads, which I do not want.=A0 Any hints
> from
> >> those who have
> >>>> implemented such garbage collectors?
> >>>>
> >>>> --
> >>>>
> >> ??????????????????????
> >>>> http://stormwyrm.blogspot.com
> >
> >>>>
> >>>>
> >>>
> >>> You don't have to pause any execution of app
> threads
> >> for a
> >>> concurrent garbage collector. A full
> concurrent
> >> garbage
> >>> collector can run as a lowest priority thread,
> and
> >> never
> >>> invoke any thr_suspend/resume the like calls.
> >>>
> >> I don't understand.=A0 Presumably you want the GC
> to run
> >> at the HIGHEST priority, so that it can't be
> >> interrupted?=A0 Even then, this makes several
> >> assumptions, which are dubious in my environment:
> >>
> >> 1) You need as many GC threads as physical
> >> processors.=A0 This seems very unfriendly to other
> >> processes on the system, unless you assume a
> >> uniprocessor.=A0 You're basically taking control of
> the
> >> whole machine, not just process.
> >>
> >> 2) Everyone needs to use a scheduling policy that
> strictly
> >> respects priorities.=A0 I think that most modern
> systems
> >> support that, but it's generally not the
> default.=A0
> >> Linux seems to require root privileges for it,
> since it
> >> allows you to take control of the whole machine.=A0
> In my
> >> experience, you want to avoid strict priorities
> whenver you
> >> can, since they introduce way too many interesting
> live-lock
> >> possibilities.
> >>
> >> 3) No other threads decide to run at the highest
> >> priority.=A0 (This one is probably OK in many
> >> environments.)
> >>
> >> 4) You can retrieve the thread states without
> cooperation
> >> of the affected threads.=A0 This is probably
> possible
> >> using debug interfaces, but tricky.
> >>
> >> This sounds like an approach that might work in
> some
> >> real-time environments, but not generally.
> >>
> >> Hans
> >
> >