<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 4/25/2013 8:15 AM, Bengt Rutisson
      wrote:<br>
    </div>
    <blockquote cite="mid:51791E4E.5020606@oracle.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix"><br>
        Hi Coleen, <br>
        <br>
        Thanks for looking at this!<br>
        <br>
        On 4/25/13 1:54 PM, Coleen Phillimore wrote:<br>
      </div>
      <blockquote cite="mid:5179196E.9060801@oracle.com" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        <div class="moz-cite-prefix"><br>
          Hi Bengt,<br>
          My memory was that all that weird code for aligning windows
          mmap space was for CDS.   Can you try your test with
          -Xshare:dump and -Xshare:on -version?<br>
          thanks,<br>
        </div>
      </blockquote>
      <br>
      Seems to work:<br>
      <br>
      >hotspot.exe -Xshare:dump<br>
      Using java runtime at: d:\java\jdk-7-fcs-bin-b148\jre<br>
      Loading classes to share ... done.<br>
      Rewriting and linking classes ... done.<br>
      Number of classes 2245<br>
      Calculating fingerprints ... done.<br>
      Removing unshareable information ... done.<br>
      ro space:   7132288 [ 36.9% of total] out of  16777216 bytes
      [42.5% used] at 0x0000000800000000<br>
      rw space:  10270832 [ 53.2% of total] out of  16777216 bytes
      [61.2% used] at 0x0000000801000000<br>
      md space:   1881528 [  9.7% of total] out of   4194304 bytes
      [44.9% used] at 0x0000000802000000<br>
      mc space:     34053 [  0.2% of total] out of    122880 bytes
      [27.7% used] at 0x0000000802400000<br>
      total   :  19318701 [100.0% of total] out of  37871616 bytes
      [51.0% used]<br>
      <br>
      >hotspot.exe -Xshare:on -version<br>
      Using java runtime at: d:\java\jdk-7-fcs-bin-b148\jre<br>
      java version "1.7.0"<br>
      Java(TM) SE Runtime Environment (build 1.7.0-b148)<br>
      Java HotSpot(TM) 64-Bit Client VM (build 25.0-b30-internal-debug,
      mixed mode, sharing)<br>
      <br>
      <br>
      I have also run JPRT on my change and I think that does some CDS
      testing, right?<br>
    </blockquote>
    <br>
    Yes, JPRT does test this with a client VM.  Does your test run with
    -Xshare:on (and hit the code that you changed)?<br>
    thanks,<br>
    Coleen<br>
    <blockquote cite="mid:51791E4E.5020606@oracle.com" type="cite"> <br>
      Thanks,<br>
      Bengt<br>
      <br>
      <blockquote cite="mid:5179196E.9060801@oracle.com" type="cite">
        <div class="moz-cite-prefix"> Coleen<br>
          <br>
          On 4/25/2013 7:09 AM, Bengt Rutisson wrote:<br>
        </div>
        <blockquote cite="mid:51790ED2.8020407@oracle.com" type="cite">
          <meta http-equiv="content-type" content="text/html;
            charset=ISO-8859-1">
          <br>
          Hi everyone,<br>
          <br>
          Could I have a couple of reviews of this change?<br>
          <a moz-do-not-send="true" class="moz-txt-link-freetext"
            href="http://cr.openjdk.java.net/%7Ebrutisso/8012915/webrev.00/">http://cr.openjdk.java.net/~brutisso/8012915/webrev.00/</a><br>
          <br>
          Background from the CR:<br>
          <br>
          <meta http-equiv="content-type" content="text/html;
            charset=ISO-8859-1">
          The method ReservedSpace::align_reserved_region() does not
          work on Windows. It tries to free parts of the previously
          allocated memory by doing two calls to os::release_memory().
          However, on Windows os::release_memory() is implemented as: <br>
          <br>
           VirtualFree(addr, 0, MEM_RELEASE) <br>
          <br>
          which will always free up all the allocated memory: <br>
          <br>
          <a moz-do-not-send="true"
href="http://msdn.microsoft.com/en-gb/library/windows/desktop/aa366892%28v=vs.85%29.aspx">http://msdn.microsoft.com/en-gb/library/windows/desktop/aa366892%28v=vs.85%29.aspx</a>
          <br>
          <br>
          "The function frees the entire region that is reserved in the
          initial allocation call to VirtualAlloc." <br>
          <br>
          This means that if ReservedSpace::align_reserved_region() is
          executed on Windows and we try to trim the beginning of the
          memory that we had allocated we will free all of the allocated
          memory. Subsequent calls to os::commit_memory() which will end
          up as: <br>
          <br>
          VirtualAlloc(addr, bytes, MEM_COMMIT, PAGE_READWRITE) <br>
          <br>
          will fail with 487, ERROR_INVALID_ADDRESS - Attempt to access
          invalid address. <br>
          <br>
          The solution is to use the existing method
          <meta http-equiv="content-type" content="text/html;
            charset=ISO-8859-1">
          os::reserve_memory_aligned() which does the same thing but
          works on all platforms.<br>
          <br>
          I assume that it is unusual that we enter this code path since
          I haven't seen a lot of crashes that seem related to this
          issue. But when we tried a patch that plays a bit with the
          alignments we crash on Windows. To have a simple reproducer I
          added a unit test. The test is not 100% fool proof, but on
          Windows without my proposed fix it fails 999 times out of 1000
          runs. With my fix it passes 100% of the time.<br>
          <br>
          Thanks,<br>
          Bengt<br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>