Re: concurrent garbage collection and POSIX threads

On Sat, 9 Jan 2010, leland wrote:

> 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 as 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 control to it, such as when all other tasks are finished 
> 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?  That seems different from the orignal question?

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  I'm attempting to
>>>> implement a  concurrent garbage collector
>> (specifically  the
>>>> Huelsbergen-Winterbottom VCGC algorithm) for a
>> small  compiled 
>>>> language I'm working on and they it requires that
>> one be 
>>> able to pause 
>>>> execution of all running threads during a
>> barrier  synchronization
>>>> event  at the end of a garbage collection
>> epoch, and then resume 
>>>> execution of  these threads afterwards.  I
>> believe many other 
>>>> concurrent garbage  collection algorithms
>> have similar
>>> requirements. 
>>>> How  would one  implement this using
>> POSIX.1b/1c primitives alone?
>>>> The pause and resume
>>>>   are in general asynchronous.  I've thought up
>> a  rather
>>> convoluted 
>>>> method that involves adding a signal handler for
>> each  thread, which
>>>> upon  receipt of a POSIX real time signal,
>> does a wait on a 
>>> condition 
>>>> variable.  When the thread is to be resumed,
>> the  condition
>>> variable is 
>>>> signaled, causing all threads waiting on it to
>> resume 
>>> execution, at 
>>>> which point the signal handler returns and
>> execution  resumes.
>>>>
>>>> I wonder if there is an easier way to do this
>> that does not require
>>>> these kinds of contortions.   There 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.  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.  Presumably you want the GC to run
>> at the HIGHEST priority, so that it can't be
>> interrupted?  Even then, this makes several
>> assumptions, which are dubious in my environment:
>>
>> 1) You need as many GC threads as physical
>> processors.  This seems very unfriendly to other
>> processes on the system, unless you assume a
>> uniprocessor.  You're basically taking control of the
>> whole machine, not just process.
>>
>> 2) Everyone needs to use a scheduling policy that strictly
>> respects priorities.  I think that most modern systems
>> support that, but it's generally not the default. 
>> Linux seems to require root privileges for it, since it
>> allows you to take control of the whole machine.  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.  (This one is probably OK in many
>> environments.)
>>
>> 4) You can retrieve the thread states without cooperation
>> of the affected threads.  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
>
>