harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [DRLVM][GC] low pause garbage collection for Harmony
Date Wed, 14 Feb 2007 12:33:32 GMT
Xiao-Feng Li wrote:
> Hi,
> 
> Harmony now has a reasonably advanced and stable parallel/generational
> GC built for 32bit platforms (the GCv5). The remaining work for GCv5 I
> think is mainly about 64bit port and leverage of large heap size
> enabled by 64bit, while performance tuning is always a continuous
> effort.

If we have GCv5 ready for testing, should we start running tests with it?

> Besides the ongoing work of GCv5, I would like to start thinking of a
> low-pause garbage collector for Harmony now, since some Harmony users
> might expect their applicaitons' execution interrupt for garbage
> collection to be as short as possible. For them, the "throughput" of
> GC is not all they want. GC's "pause time" or "latency" or "response
> time" is critical as well.
> 
> Low-pause GC usually means "concurrent GC", in contrast to
> "stop-the-world GC". In concurrent GC, the mutators (application
> threads) can keep running while collectors (GC threads) are doing
> garbage collection. GCv5 so far is a "stop-the-world" GC, where all
> the mutators are suspended when a collection is started.
> 
> The concept "parallel" is orthogonal to "concurrent". "Parallel" GC
> refers to that a collection can be conducted by multiple collector
> threads simultaneously. "Generational" is orthogonal as well.
> 
> There is a claimed "pauseless GC" by Azul Systems [1], which depends
> on Azul's specific hardware support for read/write barriers. Without
> HW support, read barriers can be expensive [2]; but I think a
> very-short-pause-time GC is acceptable for Harmony, at least good
> enough in the near future.
> 
> Some researchers seperate "on-the-fly" GC from concurrent GC as a
> special case [3]. The difference as stated is "on-the-fly" GC doesn't
> require any synchronization point where all mutators are suspended,
> i.e., it suspends and resumes mutators one after another, not at the
> same time. There is also "real-time" GC proposed that can satisfy
> required real-time bounds. Metronome is one example [4].
> 
> Considering the support in available platforms and Harmony's
> objectives, an on-the-fly GC might be our choice. But before that, we
> can have a traditional concurrent GC implemented, and adapt it into
> on-the-fly.
> 
> Anybody has good advices? Thanks.
> 
> -xiaofeng
> 
> [1] http://www.usenix.org/events/vee05/full_papers/p46-click.pdf
> [2] http://cs.anu.edu.au/~Steve.Blackburn/pubs/papers/wb-ismm-2004.pdf
> [3] http://www.cs.technion.ac.il/~erez/Papers/ms-sliding-views.ps
> [4] http://www.research.ibm.com/people/d/dfb/papers/Bacon03Realtime.pdf
> 


-- 
Gregory


Mime
View raw message