RFR: 8345569: [ubsan] filemap.cpp:2215:47: runtime error: applying non-zero offset 34358689792 to null pointer

[Matthias Baesken]

This fixes the build when building on macOS aarch64 with ubsan enabled.

Seems there is an undefined addition to a nullptr in filemap.cpp :

jdk/src/hotspot/share/cds/filemap.cpp:2215:47: runtime error: applying non-zero offset 34358689792 to null pointer
    #0 0x107b70c78 in FileMapInfo::heap_region_requested_address() filemap.cpp:2215
    #1 0x107b71960 in FileMapInfo::map_heap_region_impl() filemap.cpp:2260
    #2 0x107b70e04 in FileMapInfo::map_or_load_heap_region() filemap.cpp:2081
    #3 0x1082976ec in MetaspaceShared::map_archives(FileMapInfo*, FileMapInfo*, bool) metaspaceShared.cpp:1344
    #4 0x10829699c in MetaspaceShared::initialize_runtime_shared_and_meta_spaces() metaspaceShared.cpp:1098
    #5 0x108289530 in Metaspace::global_initialize() metaspace.cpp:736
    #6 0x108819da8 in universe_init() universe.cpp:887
    #7 0x107d8b4ec in init_globals() init.cpp:133
    #8 0x1087e43d8 in Threads::create_vm(JavaVMInitArgs*, bool*) threads.cpp:574
    #9 0x107eca96c in JNI_CreateJavaVM jni.cpp:3681
    #10 0x102e6e770 in JavaMain java.c:494
    #11 0x102e7579c in ThreadJavaMain java_md_macosx.m:679
    #12 0x19d38ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
    #13 0x19d389d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)


coding in filemap.cpp is (and CompressedOops::base() seems to return nullptr on this macoS aarch64 machine)

`return /*runtime*/ CompressedOops::base() + r->mapping_offset();
`
This was seen in the OpenJDK build on macOS aarch64 when building with ubsan enabled.

There is also another very recent issue showing up in the ubsan enabled build on macOS aarch64 since today.
jdk/src/hotspot/share/memory/virtualspace.cpp:462:18: runtime error: applying non-zero offset to non-null pointer 0x000080000000 produced null pointer
    #0 0x10a6a2df0 in ReservedHeapSpace::try_reserve_range(char*, char*, unsigned long, char*, char*, unsigned long, unsigned long, unsigned long) virtualspace.cpp:462
    #1 0x10a6a3684 in ReservedHeapSpace::initialize_compressed_heap(unsigned long, unsigned long, unsigned long) virtualspace.cpp:569
    #2 0x10a6a39cc in ReservedHeapSpace::ReservedHeapSpace(unsigned long, unsigned long, unsigned long, char const*) virtualspace.cpp:647
    #3 0x10a6a3bd0 in ReservedHeapSpace::ReservedHeapSpace(unsigned long, unsigned long, unsigned long, char const*) virtualspace.cpp:622
    #4 0x10a625d5c in Universe::reserve_heap(unsigned long, unsigned long) universe.cpp:959
    #5 0x1099d4580 in G1CollectedHeap::initialize() g1CollectedHeap.cpp:1286
    #6 0x10a6255e8 in universe_init() universe.cpp:880
    #7 0x109b95dec in init_globals() init.cpp:133
    #8 0x10a5efd98 in Threads::create_vm(JavaVMInitArgs*, bool*) threads.cpp:574
    #9 0x109cd53b4 in JNI_CreateJavaVM jni.cpp:3680
    #10 0x104d26770 in JavaMain java.c:494
    #11 0x104d2d79c in ThreadJavaMain java_md_macosx.m:679
    #12 0x19d38ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
    #13 0x19d389d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
   ... (rest of output omitted)

For now I exclude this method from ubsan checking. 
After these changes,  the build on macOS aarch64 with ubsan enabled works .

-------------

Commit messages:
 - JDK-8345569

Changes: https://git.openjdk.org/jdk/pull/22603/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22603&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345569
  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22603.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22603/head:pull/22603

PR: https://git.openjdk.org/jdk/pull/22603