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.
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
