CMS collection keep working during holiday

[Ken--@newsgroupstats.hk]

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
-XX:+ExplicitGCInvokesConcurrent

(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
>> daily
>> 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 
>> can 
>> >> 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:
>> >>
>> http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19872463.html
>> >> 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-tp19773575p19872900.html
>> 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.