<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hello, team.<br>
    <br>
    Test scenario remains old:<br>
    <ul>
      <li> Make enough space for new objects to prevent it going old. 
      </li>
      <li> allocate bunch of small objects, and a bit of humongous
        several times.
      </li>
      <li> free almost all of allocated stuff. Check that heap shrinks
        after GC.
      </li>
    </ul>
    bug:<br>
    <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8041946">https://bugs.openjdk.java.net/browse/JDK-8041946</a><br>
    <br>
    webrev: <br>
    <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~jwilhelm/8041946/webrev/">http://cr.openjdk.java.net/~jwilhelm/8041946/webrev/</a><br>
    <br>
    Currently, I've tested this patch in aurora
    (574717.ute.hs_jtreg.accept.full) and its looks like, despite of
    reducing used memory in test<br>
    it continues to fail on several boxes with OOM.<br>
    <br>
    <br>
    Thanks.<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 04.06.2014 18:40, Andrey Zakharov
      wrote:<br>
    </div>
    <blockquote cite="mid:538F2FEF.30105@oracle.com" type="cite">Hi,
      Dmitry. Thanks for corrections.
      <br>
      Here is updated webrev:
      <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~fzhinkin/azakharov/8041946/webrev.00/">http://cr.openjdk.java.net/~fzhinkin/azakharov/8041946/webrev.00/</a>
      <br>
      testing:
<a class="moz-txt-link-freetext" href="http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures&parameters=">http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures&parameters=</a>[batchNames]501230.ute.hs_jtreg.accept.full<br>
      bug: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8041946">https://bugs.openjdk.java.net/browse/JDK-8041946</a>
      <br>
      <br>
      <br>
      On 26.05.2014 19:32, Dmitry Fazunenko wrote:
      <br>
      <blockquote type="cite">Hi Andrey,
        <br>
        <br>
        Sorry, it took too long from me to review you change.
        <br>
        I have several comments:
        <br>
        - overall fix looks good
        <br>
        - I think you need to change the subject: you fix 8041946, not
        8041506
        <br>
        - Replace 'TestHumongousShrinkHeap' with
        'TestShrinkDefragmentedHeap'
        <br>
        - Make MemoryUsagePrinter as static inner class of test (to
        avoid possible conflicts with other tests)
        <br>
        - It would be good if you provide more text description to the
        test, like
        <br>
          * allocate small objects mixed with humongous ones
        <br>
              "ssssHssssHssssHssssHssssH"
        <br>
          * release all allocated object except the last humongous one
        <br>
              ".............................................H"
        <br>
          * invoke gc and check that  memory returned to the system
        (amount of committed memory got down)
        <br>
      </blockquote>
      Done
      <br>
      <blockquote type="cite">- I'm not sure that you can predict the
        expected amount of committed memory at the end... I wouldn't use
        the expectedCommitted in the test (there are many memory
        consumers, not only your test, so the final committed should be
        either less or greater than expectedCommitted )
        <br>
      </blockquote>
      Well, I have tested it a lot with JFR command line options, on all
      platforms. I found a lag with JMX on Solaris, and just put sleep
      before measure. Also I replaced run/othervm with ProcessBuilder.
      I'm planning to replace it in other early our CMM tests.
      <br>
      <blockquote type="cite">- I think you don't need to touch 
        'test/TEST.groups'. There is :needs_g1gc tests group
        (hs/test/closed/TEST.group) which lists all g1 specific tests.
        <br>
        - Please provide information on how you tested your change.
        <br>
      </blockquote>
<a class="moz-txt-link-freetext" href="http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures&parameters=">http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures&parameters=</a>[batchNames]501230.ute.hs_jtreg.accept.full
      <br>
      Thanks
      <br>
      <br>
      <blockquote type="cite">
        <br>
        Thanks,
        <br>
        Dima
        <br>
        <br>
        <br>
        On 15.05.2014 15:29, Andrey Zakharov wrote:
        <br>
        <blockquote type="cite">Hi.
          <br>
          To proper testing of free list sorting we need to defragment
          memory with small young and humongous objects
          <br>
          This is test scenario:
          <br>
          Make enough space for new objects to prevent it going old.
          <br>
           - allocate bunch of small objects, and a bit of humongous
          <br>
          several times.
          <br>
          <br>
          Free almost all of allocated stuff. Check that heap shrinks
          after GC.
          <br>
          <br>
          webrev:
          <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~jwilhelm/8041506/webrev.02/">http://cr.openjdk.java.net/~jwilhelm/8041506/webrev.02/</a>
          <br>
          bug: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8041506">https://bugs.openjdk.java.net/browse/JDK-8041506</a>
          <br>
          <br>
          Thanks.
          <br>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>