RFR (M): 8012915: ReservedSpace::align_reserved_region() broken on Windows

Coleen Phillimore coleen.phillimore at oracle.com
Thu Apr 25 11:54:22 UTC 2013


Hi Bengt,
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?
thanks,
Coleen

On 4/25/2013 7:09 AM, Bengt Rutisson wrote:
>
> Hi everyone,
>
> Could I have a couple of reviews of this change?
> http://cr.openjdk.java.net/~brutisso/8012915/webrev.00/
>
> Background from the CR:
>
> 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:
>
>  VirtualFree(addr, 0, MEM_RELEASE)
>
> which will always free up all the allocated memory:
>
> http://msdn.microsoft.com/en-gb/library/windows/desktop/aa366892%28v=vs.85%29.aspx 
>
>
> "The function frees the entire region that is reserved in the initial 
> allocation call to VirtualAlloc."
>
> 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:
>
> VirtualAlloc(addr, bytes, MEM_COMMIT, PAGE_READWRITE)
>
> will fail with 487, ERROR_INVALID_ADDRESS - Attempt to access invalid 
> address.
>
> The solution is to use the existing method 
> os::reserve_memory_aligned() which does the same thing but works on 
> all platforms.
>
> 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.
>
> Thanks,
> Bengt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130425/bf9d2b5c/attachment.htm>


More information about the hotspot-gc-dev mailing list