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

[jamsheed]

Thank you, Dean, David for review,

created a new CR for tracking bulk access failure graceful handling

https://bugs.openjdk.java.net/browse/JDK-8191278

On Wednesday 15 November 2017 04:08 AM, dean.long at oracle.com wrote:
>
> This version looks good.  If you wanted you could also do the following:
>
> CompiledMethod* nm = NULL;
> JavaThread* thread = (JavaThread*)t;
> if (in_java) {
> CodeBlob* cb= CodeCache::find_blob_unsafe(pc);
>
> because "cb" is only used in that inner block.
Ok

Best regards,
Jamsheed
>
> dl
>
> On 11/14/17 1:11 PM, jamsheed wrote:
>> Hi Dean,
>>
>> revised webrev:
>>
>> http://cr.openjdk.java.net/~jcm/6415680/webrev.01/
>>
>> i agree to the comment that it is potentially unsafe to assume the 
>> implementation, and count can be in autoincrement mode. so with this 
>> bug i would like to deal with only
>>
>> the single value access error handling.
>>
>> revised webrev: http://cr.openjdk.java.net/~jcm/6415680/webrev.01/
>>
>> Best regards,
>>
>> Jamsheed
>>
>>
>>
>> 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.
>>>
>>>> 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?
>>>
>>> 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?
>>>
>>> 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.
>>>
>>> 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?
>>>
>>> dl
>>>
>>>> Best regards, Jamsheed
>>>>
>>>
>>
>