Where have the Full GCs gone?

[Peter B. Kessler]

You can *reserve* more virtual memory than you have physical memory.  You just won't be happy when you exceed the amount of physical memory you have.

How much physical memory do you have?  If it's, say 8GB, you might not be to the point of paging, so things will look fine.  But I suspect that at some point your application time and your GC times will rise as you need to page the heap to follow references.  Usually that's a pretty steep cliff.

This is Apple's port of JDK-1.5.0_13, right?  I can't imagine that they changed the output format.

			... peter

Moazam Raja wrote:
> Peter, this must be a bug in the GC output as I know for sure I don't 
> have the memory to run a 20GB heap.
> 
> Instead of 20950272K, it must mean 20950272K*b*.
> 
> This is on Java 1.5.0 on OS X Leopard.
> 
> java version "1.5.0_13"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
> Java HotSpot(TM) Server VM (build 1.5.0_13-119, mixed mode)
> 
> 
> -Moazam
> 
> On Nov 4, 2008, at 4:52 PM, Peter B. Kessler wrote:
> 
>> Moazam Raja wrote:
>>> Hi all, I'm running a test and recording GC information on a Tomcat 
>>>  application and have noticed that even after a few days, there are 
>>> no  'Full GC' markers. Am I reading the log incorrectly, or are the 
>>> Full  GCs getting logged elsewhere?
>>> I'm using Java 1.5.0_13 on OS X with the following flags,
>>>         -Xms=2048m -Xmx=2048m
>>>         -server -XX:+UseConcMarkSweepGC
>>>         -Xloggc:/var/tmp/GC.log
>>>         -verbose:gc
>>>         -XX:+PrintGCDetails
>>>         -XX:+PrintHeapAtGC
>>>         -XX:+PrintClassHistogram
>>>         -XX:+PrintGCApplicationConcurrentTime
>>> A sample of the output from my GC log:
>>> Application time: 1.4105823 seconds
>>> 82558.187: [GC {Heap before gc invocations=111716:
>>>  par new generation   total 21184K, used 21120K [0x0000000107270000, 0x0000000108730000, 0x0000000108730000)
>>>   eden space 21120K, 100% used [0x0000000107270000, 0x0000000108710000, 0x0000000108710000)
>>>   from space 64K,   0% used [0x0000000108710000, 0x0000000108710000, 0x0000000108720000)
>>>   to   space 64K,   0% used [0x0000000108720000, 0x0000000108720000, 0x0000000108730000)
>>>  concurrent mark-sweep generation total 20950272K, used 5483440K [0x0000000108730000, 0x0000000607270000, 0x0000000607270000)
>>>  concurrent-mark-sweep perm gen total 39296K, used 23575K [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000)
>>> 82558.187: [ParNew: 21120K->0K(21184K), 0.0669633 secs] 5504560K->5487545K(20971456K)Heap after gc invocations=111717:
>>>  par new generation   total 21184K, used 0K [0x0000000107270000, 0x0000000108730000, 0x0000000108730000)
>>>   eden space 21120K,   0% used [0x0000000107270000, 0x0000000107270000, 0x0000000108710000)
>>>   from space 64K,   0% used [0x0000000108720000, 0x0000000108720000, 0x0000000108730000)
>>>   to   space 64K,   0% used [0x0000000108710000, 0x0000000108710000, 0x0000000108720000)
>>>  concurrent mark-sweep generation total 20950272K, used 5487545K [0x0000000108730000, 0x0000000607270000, 0x0000000607270000)
>>>  concurrent-mark-sweep perm gen total 39296K, used 23575K [0x0000000607270000, 0x00000006098d0000, 0x000000060c670000)
>>> }
>>> , 0.0672098 secs]
>>> ...
>>
>> I don't think those are the command line arguments for the GC log you 
>> show.  It looks from the PrintHeapAtGG output that your heap is 20GB, 
>> not the 2GB shown on the command line.  20MB in the "par new" 
>> generation, and the reast of the 20GB in the CMS generation.
>>
>> It looks like you are using just over 5GB of CMS space, which would 
>> explain why you haven't seen an old generation collection yet.
>>
>> ... peter
>