Re: Daily gclist MIME digest V5 #121

Eliot, 

"Fully Concurrent" sounds much better, I like it.

and thank you very much for your support. 

kind regards,

- Mingnan Guo


--- On Mon, 1/11/10, Eliot Moss <[email protected]> wrote:

> From: Eliot Moss <[email protected]>
> Subject: Re: [gclist] Daily gclist MIME digest V5 #121
> To: "Mingnan Guo" <[email protected]>
> Cc: "Erez Petrank" <[email protected]>, [email protected]
> Received: Monday, January 11, 2010, 5:37 PM
> On 1/11/2010 6:52 PM, Mingnan Guo
> wrote:
> > Hi all,
> >
> > I want to say something about the terminology of
> "Concurrent", "On-The-Fly" and "Full Concurrent".
> >
> > Many technical papers have used the term "Concurrent"
> and "On-The-Fly" regarding stack scanning as:
> >
> > "Concurrent garbage collectors run concurrently with
> the application and only stop it for a short synchronization
> phase in the beginning or end of the collection. On-the-fly
> collectors are special concurrent collectors that never need
> to stop all threads simultaneously. They stop the
> application one thread at a time typically for scanning the
> thread runtime stack"
> >
> > However, some concurrent GC algorithms do not perform
> stack scanning at all. As far as I know, there are at least
> two implementations of that kind of GC. One is HnxGC based
> on reference counting, another one is not reference counting
> based. These kinds of GCs are so much different from those
> "Concurrent" and "On-The-Fly" on stack scanning. So, using a
> different terminology, such as "Full Concurrent", is more
> appropriate for these GC algorithms to avoid confusion. For
> example,
> >
> > "Full Concurrent garbage collectors run concurrently
> with the application and behave like usual application
> threads, which never involuntarily stop other threads except
> for debug purpose."
> >
> > Any comment? Thanks,
> >
> > -Mingnan Guo
> 
> In slightly more colloquial English, I would say "Fully
> Concurrent".
> 
> Concerning "Concurrent" versus "On-the-fly", I would agree
> that the
> difference is whether all threads are stopped at once. It
> is indeed
> possible to write collectors where the mutators never need
> to block
> (unless storage is exhausted; with adequate resources,
> bounds on
> mutator allocation rate, etc., it is possible to avoid
> storage
> exhaustion). However, such approaches may need more
> frequent or
> more costly read or write barriers in the mutators.
> Reference
> counting meeds to be augmented with a cycle collector, and
> in
> general you may still need to support compaction in order
> to
> repair fragmentation ....
> 
> Best wishes -- Eliot Moss
>