RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully

[Jamsheed]

Hi Tobias

On 12/03/19 8:38 PM, Tobias Hartmann wrote:
> Hi Harold,
>
> so we are checking with StubRoutines::contains() if we are inside StubRoutines::unsafe_arraycopy(),
> right? What if StubRoutines::contains(pc) returns true but we actually hit a SIGBUS inside another stub?

Thank you for the review.

from the comments it says "StubRoutines are used by Compiled code and 
runtime system". and StubRoutines::contains(pc) is expected be checked 
under code running in Java condition.

missed adding is_Java check only in windows. later i had corrected it in 
fast failure handling code[1], but missed putting it in the code under 
review.

i presumed the stub routine[2] code  sigbus memory access error could 
happen only in case of Unsafe. but will double check.

Best regards,

Jamsheed

[1]http://cr.openjdk.java.net/~jcm/temp/fastfail.00/src/hotspot/os/windows/os_windows.cpp.udiff.html

[2] Java stubRotuines code

>
> I also noticed that some changed lines have a broken indentation, for example, os_bsd_zero.cpp:197.
>
> Best regards,
> Tobias
>
> On 28.02.19 21:22, Harold Seigel wrote:
>> Hi,
>>
>> Please review this fix for JDK-8191278.  The fix uses the GuardUnsafeAccess class in unsafe.cpp so
>> that the signal handler will know to convert SIGBUS signals to exceptions.
>>
>> The compiler related changes and much of the test were written by Jamsheesh (jcm).
>>
>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8191278/webrev/index.html
>>
>> JBS Bug:  https://bugs.openjdk.java.net/browse/JDK-8191278
>>
>> The fix was tested on Linux x64, Mac OS, Solaris Sparc, and Windows.  Testing was not done on the
>> other platforms changed by this fix.
>>
>> The fix was regression tested by running Mach5 tiers 1 and 2 tests and builds on Linux x64, Solaris,
>> Windows, and Mac OS X, by running Mach5 tiers 3 -5 on Linux x64, and by running JCK-13 Lang and VM
>> tests on Linux x64.
>>
>> Thanks, Harold
>>