<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
On 4/25/13 2:34 PM, Coleen Phillimore wrote:<br>
</div>
<blockquote cite="mid:517922E9.6020502@oracle.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<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>
</blockquote>
<br>
Thanks for asking this, Coleen! <br>
<br>
It turns out that we don't hit the code. And the reason that we
don't hit it is that it is dead code. Thanks for making me try this!<br>
<br>
I'll send out a new webrev where this code is removed instead.<br>
<br>
Here's why I thought this was used if anyone wonders:<br>
<br>
This code is in use in JDK7 where PermGen still exists. I found the
issue there and started fixing it. It turns out to be more difficult
to fix it there, and I realized it would be a very simple fix in
JDK8. I already had the test and ported the test to JDK8. The test
reproduced the issue and I fixed the problem not realizing that my
test was the only user of this code now. And I figured I'd send the
change out for review and then go back to fixing this in JDK7.<br>
<br>
I guess that I will now send out a review for removing this code in
JDK8 and then go back to how we should handle this in JDK7.<br>
<br>
Thanks,<br>
Bengt<br>
<br>
<blockquote cite="mid:517922E9.6020502@oracle.com" type="cite">
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>
</blockquote>
<br>
</body>
</html>