harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [DRLVM][GC] low pause garbage collection for Harmony
Date Wed, 14 Feb 2007 12:44:20 GMT

On Feb 14, 2007, at 7:33 AM, Gregory Shimansky wrote:

> 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?

That was going to be my suggest - start testing and evaluate how it  
performs against v4, how it does w/ the test suites, and then decide  
if it's time to switch to it.

geir

>
>> 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