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: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Date Sat, 16 Sep 2006 12:58:21 GMT


Robin Garner wrote:
> Designing a garbage collector with low pause times and high throughput (ie
> low overhead) is to an extent the 'holy grail' of memory management
> research.

Do you know much about this on in JRockit?

http://www.networkcomputing.com/showArticle.jhtml?articleId=193000182

(They used Geronimo to test too.  w00t!)

> 
> The worst case pause times are in full heap collectors, where the pause
> time is proportional to the total number of live objects in the heap.
> 
> Generational collection helps drive down the average pause time (nursery
> collections are cheap) but the maximum pause time (when the mature space
> needs collecting) is much the same as a full heap collector.  A
> generational collector with a bounded nursery can shorten the time of
> minor collections, but has lower throughput and the same maximum pause
> time.
> 
> To an extent, most of the literature on GC addresses this issue, and some
> things you might like to read up on are:
> 
> - Metronome.
>   This pushes pause times down into the sub-millisecond realm, but at a
> considerable (although predictable) overhead.
> 
> - The Sun 1.5 JVM, which has an optional concurrent collector for the
> mature space
> 
> - Ulterior Reference Counting, which combines the high throughput of a
> generational collector with the low pause times of reference counting.
> 
> - Beltway, which collects the heap in small chunks, after giving objects
> time to die
> 
> - Free-me, which automatically identifies short-lived objects
> 
> Just to name a few.
> 
> cheers
> 
>> Leo Li wrote:
>>> Hi,all:
>>>    As we all know, java objects are allocated on heap instead of stack,
>>> thus there is a problem about how to garbage collect short-lived objects
>>> quickly.
>>>    In a recent real project I involved, a server built on java tries to
>>> send thousands of messages to client per second. A lot of short-lived
>>> messages is created as objects and discarded. (Although I can recycle
>>> these
>>> memory, there is still a byte array created during per call of nio read
>>> and
>>> write.) Since current GC strategy adopted by current RI starts to work
>>> only
>>> when the memory allocated approaching the limit of java heap, the work
>>> of GC
>>> is huge and will raise a wave on the server performance. Furthermore,
>>> after
>>> a long run, although I know GC will merge memory, the operating system
>>> reports there is memory fragment and in the worst case the OS will even
>>> report real memory is exhausted.
>>>    Of course it is possible to limit the java heap so as to force gc
>>> frequently as a workround, is it preferrable to collect short-lived
>>> objects
>>> quickly such as adopt aged-related object queues as one of the gc
>>> strategy?
>>>   What about the VMs here, drlvm or J9?
>>>
>> Interesting topic, I'm still dreaming of "free()" in Java (This dream
>> begins at the very beginning when I see Java, as C/C++ is my first
>> program language )However, it seems RI will never give us "free()". :)
>>
>> Only a thought, Java may offer a key word "temp", indicating that this
>> variety can be freed at once.
>>
>>> Leo Li
>>> China Software Development Lab, IBM
>>>
>>
>> --
>>
>> Best Regards!
>>
>> Jimmy, Jing Lv
>> China Software Development Lab, IBM
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message