<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Florian,<br>
    <br>
    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.<br>
    <br>
    Tony<br>
    <br>
    On 12/09/2011 09:08 PM, Florian Binder wrote:
    <blockquote cite="mid:4EE2BF0D.1050005@java4.info" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      In the gc log it seems that there is always running the same
      garbage collection.<br>
      For example:<br>
      $ zcat out_err.log.gz | grep 20480M | tail<br>
      2011-11-28T19:13:19.482+0100: [GC cleanup
      14515M->14515M(20480M), 0.1370060 secs]<br>
         [ 16394M->12914M(20480M)]<br>
         [ 16394M->12914M(20480M)]<br>
      2011-11-28T19:17:12.509+0100: [GC cleanup
      15582M->15582M(20480M), 0.1387230 secs]<br>
         [ 16394M->12914M(20480M)]<br>
         [ 16394M->12914M(20480M)]<br>
         [ 16394M->12914M(20480M)]<br>
      2011-11-28T19:21:06.089+0100: [GC cleanup
      12978M->12978M(20480M), 0.1344170 secs]<br>
         [ 16394M->12914M(20480M)]<br>
         [ 16394M->12914M(20480M)]<br>
      <br>
      Therefore I assume this might be a bug ;-)<br>
      You can download the whole log at: <a moz-do-not-send="true"
        class="moz-txt-link-freetext"
        href="http://java4.info/g1/out_err.log.gz">http://java4.info/g1/out_err.log.gz</a><br>
      <br>
      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.<br>
      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%.<br>
      <br>
      Flo<br>
      <br>
      <br>
      <br>
      Am 10.12.2011 01:34, schrieb Srinivas Ramakrishna:
      <blockquote
cite="mid:CABzyjynoUfeND2NPoFCeDONcq9=yX1XwUVzzhuO0BZX_Rt=fcw@mail.gmail.com"
        type="cite"><br>
        <br>
        A couple of things caught my eye....<br>
        <br>
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div> On 12/05/2011 02:19 PM, Florian Binder wrote:<br>
              >> I assume you know when the data will be dropped
              and reinitialized,<br>
              >> right? Can you do a Full GC (with System.gc())
              after you re-initialize<br>
              >> the heap. This typically helps a lot with CMS.<br>
              > Yes, this is exactly what we are trying at this time
              ;-)<br>
              > Either this Full-GC pauses are very long (60-300
              seconds) they are much<br>
              > shorter than after a CMS-failure (when they take
              sometimes more than<br>
              > 4000 seconds ;-)) and we can define when they occure.<br>
            </div>
          </blockquote>
          <div><br>
            A full GC that takes an hour is definitely a bug. Have you
            logged that bug?<br>
            Or at least share the GC log? What's the version of the JDK
            that this behaviour<br>
            was seen with?<br>
             <br>
          </div>
          <div>... <br>
          </div>
          <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div> > Furthermore this should not increase the
              total-heap-space:<br>
              > <a moz-do-not-send="true"
                href="http://java4.info/g1/all.png" target="_blank">http://java4.info/g1/all.png</a><br>
            </div>
          </blockquote>
          <div><br>
             Remember that jconsole asynchronously samples the heap,
            whose size is<br>
            read "with possible glitches". Rather, you should probably
            rely on the GC log in order to assess<br>
            the heap size after each GC event, rather than the
            asynchronous samples from<br>
            jconsole. I myself have not had the chance to look at yr GC
            logs to see<br>
            what that indicated wrt the size of Eden and of the Heap.<br>
            <br>
            -- ramki<br>
          </div>
        </div>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
hotspot-gc-use mailing list
<a class="moz-txt-link-abbreviated" href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a>
<a class="moz-txt-link-freetext" href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a>
</pre>
    </blockquote>
  </body>
</html>