100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application

[Jon Masamitsu]

David,

This is an educated guess but I would say that no out-of-memory
was thrown because there was still significant space in the
young gen after a collection.

62712.664: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 
683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen:

The young gen capacity being 214720K and the used space
in the young gen being  98240K.  That missing space may be in the
survivor spaces which are not directly available to the
application with the UseParallelGC collector.  The logic
that would throw the out-of-memory is very conservative
and probably does not allow for such a case.

Jon



David Sitsky wrote On 02/25/09 13:59,:

>Hi Ramki,
>
>The next message I posted to the hotspot list showed a GC trace when I 
>allocated more memory (an extra 300 megs), where everything worked fine. 
>  I am well aware that the heap size for this particular application and 
>data set was too small.  My run from last night with the extra heap is 
>still running nicely.
>
>I reported this issue, because it seemed to me no progress was being 
>made and no OutOfMemoryErrors were being generated.  The application was 
>effectively "stuck" making no progress at all.  I couldn't even connect 
>to it with jconsole, although jstack worked fine.
>
>My understanding is this condition is meant to be detected, and 
>OutOfMemoryError is meant to be thrown, but perhaps I am mistaken?  This 
>is with the parallel GC.
>
>Cheers,
>David
>
>Y Srinivas Ramakrishna wrote:
>  
>
>>Doesn't the heap look too full?
>>If a 64-bit JVM why use such an oversubscribed
>>and small heap? Either make the old gen bigger or make the
>>young gen smaller (giving that space to the older gen)
>>so that each scavenge does not degenerate to a full gc
>>as in your trace below.
>>
>>This discussion probably belongs on hotspot-gc-use at o.j.n list
>>so i have cross-posted over to that list with a bcc to
>>the hotspot-dev list.
>>
>>Also the GC tuning guides to be found here might be useful
>>reading:-
>>
>>http://java.sun.com/javase/technologies/hotspot/gc/index.jsp
>>
>>-- ramki
>>
>>----- Original Message -----
>>From: Jon Masamitsu <Jon.Masamitsu at Sun.COM>
>>Date: Tuesday, February 24, 2009 10:00 pm
>>Subject: Re: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application
>>To: David Sitsky <sits at nuix.com>
>>Cc: hotspot-dev at openjdk.java.net, Tom Rodriguez <Thomas.Rodriguez at Sun.COM>
>>
>>
>>    
>>
>>>David,
>>>
>>>Can you also send a GC log from a run where there
>>>is not a problem?  As I understand it, that would
>>>be a 32bit run.
>>>
>>>Jon
>>>
>>>David Sitsky wrote On 02/24/09 16:04,:
>>>
>>>      
>>>
>>>>Jon Masamitsu wrote:
>>>> 
>>>>
>>>>        
>>>>
>>>>>Jon Masamitsu wrote On 02/23/09 17:20,:
>>>>>
>>>>>   
>>>>>
>>>>>          
>>>>>
>>>>>>...
>>>>>>
>>>>>>Increase the heap by 30%.  Also increase the the perm gen size
>>>>>>(-XX:MaxPermSize=<nn>).
>>>>>>
>>>>>>Please use -XX:+PrintGCDetails -XX:+PrintGCTimeStamps when 
>>>>>>            
>>>>>>
>>>gathering the
>>>      
>>>
>>>>>>GC  logs.
>>>>>>If you've already gathering some, send those but in future runs, 
>>>>>>            
>>>>>>
>>>use the
>>>      
>>>
>>>>>>above.
>>>>>>     
>>>>>>
>>>>>>            
>>>>>>
>>>>Here is a sample of output from a stuck process.  You can see its 
>>>>        
>>>>
>>>doing 
>>>      
>>>
>>>>a full GC about every 3 seconds, and it seems as if there is little 
>>>>progress..
>>>>
>>>>Please let me know if you need more information.
>>>>
>>>>Cheers,
>>>>David
>>>>
>>>>
>>>>
>>>> 
>>>>
>>>>        
>>>>
>
>_______________________________________________
>hotspot-gc-use mailing list
>hotspot-gc-use at openjdk.java.net
>http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>  
>

_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use