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

Mikael Vidstedt mikael.vidstedt at oracle.com
Fri May 17 14:02:53 PDT 2013


David,

Thanks for the comments! New webrev available here (and some comments 
below):

http://cr.openjdk.java.net/~mikael/webrevs/8013726/webrev.04/webrev

On 2013-05-16 18:54, David Holmes wrote:
> 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

Fixed.

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

I could, but I'm not sure it makes the code significantly better so I'd 
probably rather keep it the way it is if that's ok with you.

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

The new version now checks explicitly for that and throws a helpful 
exception.

> ---
>
> Otherwise changes seem to address problems described.
>
> What testing has now been carried out? Presumably OSX was not tested 
> previously.

My mistake last time was to not realize that the new test was not picked 
up and run as part of the normal jprt submit. As part of fixing the test 
I manually ran/verified the test on the (other) platforms and I have 
also explicitly run the test through JPRT (using -rtests 
'*-*-*-runtime/memory').

Anything recommendations on additional things to test?

Cheers,
Mikael

>
> 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
>>



More information about the hotspot-runtime-dev mailing list