CMS collection keep working during holiday
dragonken at gmail.com
Wed Oct 8 08:13:17 UTC 2008
Thanks to your quick response.
You are correct.
I use this option set to find out how large is my lived objects:
-Xmx1536M -Xms1536M -XX:NewSize=256M -XX:MaxNewSize=256M
(Yes, pressing Full-GC in jconsole or call System.gc() in application can
have same effect.)
The application will daily reset all lived objects at 9:00am(holiday or
non-trading day will not). Day open at 9:30am and day end at 4:30pm. From
jconsole, I can see the heap chart raise steadily from 80M(9:30am) to
5xxM(4:30pm), if use the vm options above.
Y Srinivas Ramakrishna wrote:
> Let me see if i understood that:-
>> What the application is simply a stock quote client server and store
>> stock quote and chart data in memory. The lived objects need around 80M
>> memory at day open and 500M memory at day end.
> So you expect that the long-lived objects that will eventually get
> promoted into the old generation, will start out at about 80 MB
> at the start of the trading day and will end up about 500 MB at the
> end of the trading day.
> What happens at the end of the trading day? Do you discard the entire
> table, so that the set of long-lived objects would be expected to shrink
> back to 80 MB after the trading day ends?
> If I understood your problem correctly (and correct me if i am wrong)
> you find that the old gen occupancy does not shrink down with
> concurrent collections at the end of the trading day, but shrinks only
> upon a mark-compact collection (which typically happens as a result of
> a promotion failure).
> (Loud thinking: I am assuming that the same effect would be achieved
> by calling a System.gc() at the end of the trading day after the
> table of quotes has been dropped. Of course, we need to figure out
> why CMS may not reclaim the table even though it has been dropped.]
> Please correct any misunderstanding of the situation.
> -- ramki
>> y.s.ramakrishna wrote:
>> > Could you run with the additional option +PrintReferenceGC and see if
>> > it sheds additional light on the problem? (Please share the resulting
>> > GC logs.)
>> > If at all possible, you might try rev'ing down to 6.0 and seeing
>> > if the same behaviour reproduces or not?
>> > I understand that some or all of this may not be possible in a
>> > production setting.
>> > -- ramki
>> > ----- Original Message -----
>> > From: "Ken-- at newsgroupstats.hk" <dragonken at gmail.com>
>> > Date: Tuesday, October 7, 2008 10:17 pm
>> > Subject: Re: CMS collection keep working during holiday
>> > To: hotspot-gc-dev at openjdk.java.net
>> >> Follow up to the jconsole above. This gif is captured today. You
>> >> see the
>> >> first CMS after a FULL GC is working. The 2nd one is working too
>> but the
>> >> memory free from 2nd generation is much less than the first CMS. The
>> >> memory
>> >> free by 3rd CMS is further decreased.
>> >> The 5th CMS cannot free enough memory to make occanpcy in old-gen
>> to less
>> >> than 70%. So, continue non-stopping CMS happen again until a Full GC
>> >> (triggered by Concurrent Mode Failure).
>> >> http://www.nabble.com/file/p19872463/jconsole_20081008.jpg
>> >> --
>> >> View this message in context:
>> >> Sent from the OpenJDK Hotspot Garbage Collection mailing list
>> >> at Nabble.com.
>> View this message in context:
>> Sent from the OpenJDK Hotspot Garbage Collection mailing list archive
>> at Nabble.com.
View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19874318.html
Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com.
More information about the hotspot-gc-dev