When accessing a memory mapped file that is truncated, we might get a SIGBUS error. We translate those errors into Java exceptions in order to avoid VM crashes. This is done by 'guarding' a memory access, which entails setting a thread-local flag to indicate we are doing an unsafe access. The signal handler then translates the SIGBUS into an exception when it sees that the flag is set.

This behavior was introduced as pat of: https://bugs.openjdk.org/browse/JDK-8191278

But, the original fix was not applied to Unsafe_SetMemory0. Hence, it is possible to get a SIGBUS VM crash when using setMemory through e.g. MemorySegment::fill. (See attached test changes):

#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGBUS (0x7) at pc=0x00007f4f601afe6c, pid=30985, tid=31010
#
# JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-2023-11-28-1136385.jvernee...)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-2023-11-28-1136385.jvernee..., mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C [libc.so.6+0x18ee6c]
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jvernee/jdk/open/build/linux-x64-debug/test-support/jtreg_test_hotspot_jtreg_runtime_Unsafe_InternalErrorTest_java/scratch/0/core.30985)
#