CMS collection keep working during holiday

[Ken--@newsgroupstats.hk]

Thanks to your quick response. 

There is around 13000 listed stocks in my local stock market and over 80% of
them have transaction. There are 285 minutes in trading hours so number of
instance of ObjPriceLog is around 3,000,000 which is expected.

I have no idea why there are so many HashMap$Entry. I suspect that's come
from com.sun.jmx.remote.util.OrderClassLoaders.

Actually jmap -histo is my first step for trouble shooting at the very
beginning. Why there are so many wierd instance is because I have this flag:

-XX:+DisableExplicitGC

With this flag turned on, all calls to System.gc() is ignored even you press
the 'Perform-GC' button in Jconsole. Removing this flag will have a much
clear histo. I will cap a histo (without this flag turned on) and post here
tomorrow.

I will try to use jhat to figure why there are so many soft reference (and
firstly, I have to learn what soft reference is) and where is those
HashMapEntrys come from.

Thanks to all of you and your professional comment!

Best Regards,
Ken



kirk-17 wrote:
> 
> Ken-- at newsgroupstats.hk wrote:
>> Attached.
>> http://www.nabble.com/file/p19882121/histo.txt histo.txt 
>>   
> wierd, HashMap$Entry is the top item in the list.. 666 soft references 
> and a bunch of weak references. The interesting one is 
> com.mycompany.objs.ObjPriceLog. Have you sed'ed this file ;-)... Why is 
> ObjPriceLog hanging about?
> 
> Regards,
> Kirk
>>
>>
>>
>> antonios.printezis wrote:
>>   
>>> jmap -histo too
>>>
>>> Tony
>>>
>>> kirk wrote:
>>>     
>>>> Ken-- at newsgroupstats.hk wrote:
>>>>       
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   
>>>>>         
>>>> If GC is failing to recover memory, you either have a memory leak or 
>>>> long loitering objects. I'd suggest visualvm or netbeans memory 
>>>> profiling using the generations option to find out what objects are 
>>>> surviving
>>>>
>>>> Regards,
>>>> Kirk
>>>>       
>>> -- 
>>> ---------------------------------------------------------------------
>>> | Tony Printezis, Staff Engineer   | Sun Microsystems Inc.          |
>>> |                                  | MS UBUR02-311                  |
>>> | e-mail: tony.printezis at sun.com   | 35 Network Drive               |
>>> | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA |
>>> ---------------------------------------------------------------------
>>> e-mail client: Thunderbird (Linux)
>>>
>>>
>>>
>>>
>>>     
>>
>>   
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/CMS-collection-keep-working-during-holiday-tp19773575p19891748.html
Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com.