RFR(S): Fix regression test for 8012015 (Use PROT_NONE when reserving memory)

[David Holmes]

On 17/05/2013 2:39 AM, Mikael Vidstedt wrote:
>
> Please review the below change:
>
> Webrev:
> http://cr.openjdk.java.net/~mikael/webrevs/8013726/webrev.03/webrev/
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013726

src/share/vm/prims/whitebox.cpp

Typo: elimnated

Couldn't you just return the value read to ensure the compiler doesn't 
eliminate the read?

What if p is NULL? (Unlikely I know but ...)

---

Otherwise changes seem to address problems described.

What testing has now been carried out? Presumably OSX was not tested 
previously.

Thanks,
David


>
> Background (see bug report for some additional information):
>
> When changing the protection for reserved memory [1][2] I also added a
> regression test. The test is supposed to reserve a memory range and
> explicitly provoke a crash by accessing that memory. Unfortunately the
> test is severely broken and does not work on all platforms. Specifically
> it has the following problems:
>
> * It tries to reserve a 4kb memory range, which is not always allowed -
> os::vm_allocation_granularity() is the memory allocation granularity.
> For example, on my windows machine the granularity is 64kb. This
> triggers the assert in the bug report.
>
> * The test also uses Unsafe to do the memory access, but signals raised
> by Unsafe operations are handled slightly differently from normal memory
> accesses. Specifically, a SIGBUS signal is translated into a Java
> exception. Furthermore, on OSX a memory access in reserved memory raises
> a SIGBUS whereas on other platforms (Linux, Solaris) it is a SIGSEGV.
>
>
> About the change:
>
> The change resolves the assert by using os::vm_allocation_granularity()
> when specifying the size of the reserved memory.
>
> In order to avoid the Unsafe specific behavior in combination with the
> platform specific signal raised the memory access has also been moved
> into the native whitebox code. The function now both does the memory
> reservation and touches the memory and it has been renamed to reflect
> that. One alternative to that would be to have a separate whitebox
> function to read from a memory address, but that did not immediately
> make sense. Future tests may want to revisit that.
>
> Thanks,
> Mikael
>
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012015
> [2] http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f32b6c267d2e
>