G1 discovers same garbage again?

[Florian Binder]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111210/627b7dfc/attachment.htm>
-------------- next part --------------
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use