[10]RFR: 6415680: (bf) MappedByteBuffer.get() can provoke crash with EXCEPTION_IN_PAGE_ERROR

jamsheed jamsheed.c.m at oracle.com
Tue Nov 14 19:32:02 UTC 2017

Hi Dean,

Thank you for the feedback,

On Tuesday 14 November 2017 11:57 PM, dean.long at oracle.com wrote:
> Adding runtime alias...
> comments inlined below.
> On 11/13/17 9:10 PM, jamsheed wrote:
>> Hi, request for review, jbs: 
>> https://bugs.openjdk.java.net/browse/JDK-6415680 webrev: 
>> http://cr.openjdk.java.net/~jcm/6415680/webrev.00/ Description: 1) 
>> changes equivalent to JDK-4454115 is done for windows.
> It looks like "nm" can be uninitialized if "in_java" is false.
that was a miss, thank you for pointing that.
>> 2) added guard to multiple value access sites, Unsafe_CopyMemory0, 
>> Unsafe_SetMemory0 and Unsafe_CopySwapMemory0.
> Can you narrow the scope of the unsafe access using something like 
> GuardUnsafeAccess, instead of marking the whole function as doing 
> unsafe access?
can do that, but i don't find an issue with putting guard for the whole 
> There are some risks with trying to  abort a copy function.
> First, won't we get multiple exceptions until we finally hit the end 
> of the range?  What if the bad range is very large?
we may get multiple exception, and we may reach safepoint a bit late, 
this should be case in compiled code too, where we use intrinsics
> Second, what if the loop is using auto-increment instructions? 
> Skipping to the next instruction would mean we loop forever if the 
> increment never happens.
we move to next instruction, so will exit loop, no backward branching 
right ?
> I think if we are going to safely abort copy functions then we need to 
> register them as a kind of CodeBlob that has a special abort entry 
> point or exception handler we can redirect to, or maybe pop the whole 
> frame and return.
> Is there really a problem with these copy functions?  I'm wondering 
> why Mikael did not identify these as a problem in 8154592.
>> 3) Unsafe_CopySwapMemory0 is JVM_LEAF so removed 
>> thread->thread_state() == _thread_in_vm checks from signal handler
> How about adding a check for _thread_in_native instead of removing the 
> check entirely?
ok i will add that.
Best regards,

> dl
>> Best regards, Jamsheed

More information about the hotspot-compiler-dev mailing list