G1 discovers same garbage again?

[Tony Printezis]

Florian,

Not sure what you mean by "the same GC". It is because the space 
transition looks like: 16394M->12914M(20480M)? This is normal. Heap 
occupancy reaches 16394M, GC happens, heap occupancy goes down to 
12914M. Next time it happens, the heap will have new objects. This is 
how GCs work.

Tony

On 12/09/2011 09:08 PM, Florian Binder wrote:
> In the gc log it seems that there is always running the same garbage 
> collection.
> For example:
> $ zcat out_err.log.gz | grep 20480M | tail
> 2011-11-28T19:13:19.482+0100: [GC cleanup 14515M->14515M(20480M), 
> 0.1370060 secs]
>    [ 16394M->12914M(20480M)]
>    [ 16394M->12914M(20480M)]
> 2011-11-28T19:17:12.509+0100: [GC cleanup 15582M->15582M(20480M), 
> 0.1387230 secs]
>    [ 16394M->12914M(20480M)]
>    [ 16394M->12914M(20480M)]
>    [ 16394M->12914M(20480M)]
> 2011-11-28T19:21:06.089+0100: [GC cleanup 12978M->12978M(20480M), 
> 0.1344170 secs]
>    [ 16394M->12914M(20480M)]
>    [ 16394M->12914M(20480M)]
>
> Therefore I assume this might be a bug ;-)
> You can download the whole log at: http://java4.info/g1/out_err.log.gz
>
> I don't think that we still have the logs of that very long gc, but I 
> will have a look for it at monday.
> Furthermore I do not think that we have logged there much details of 
> the gc. But I know that this happend on a very special server, which 
> contains more the 30gb of references (yes, just references to other 
> objects). If we run it with CompressedOops we reduce the memory useage 
> to nearly 50%.
>
> Flo
>
>
>
> Am 10.12.2011 01:34, schrieb Srinivas Ramakrishna:
>>
>>
>> A couple of things caught my eye....
>>
>>     On 12/05/2011 02:19 PM, Florian Binder wrote:
>>     >> I assume you know when the data will be dropped and reinitialized,
>>     >> right? Can you do a Full GC (with System.gc()) after you
>>     re-initialize
>>     >> the heap. This typically helps a lot with CMS.
>>     > Yes, this is exactly what we are trying at this time ;-)
>>     > Either this Full-GC pauses are very long (60-300 seconds) they
>>     are much
>>     > shorter than after a CMS-failure (when they take sometimes more
>>     than
>>     > 4000 seconds ;-)) and we can define when they occure.
>>
>>
>> A full GC that takes an hour is definitely a bug. Have you logged 
>> that bug?
>> Or at least share the GC log? What's the version of the JDK that this 
>> behaviour
>> was seen with?
>>
>> ...
>>
>>     > Furthermore this should not increase the total-heap-space:
>>     > http://java4.info/g1/all.png
>>
>>
>>  Remember that jconsole asynchronously samples the heap, whose size is
>> read "with possible glitches". Rather, you should probably rely on 
>> the GC log in order to assess
>> the heap size after each GC event, rather than the asynchronous 
>> samples from
>> jconsole. I myself have not had the chance to look at yr GC logs to see
>> what that indicated wrt the size of Eden and of the Heap.
>>
>> -- ramki
>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111212/c69c38be/attachment.htm>