SafeFetch is important - mostly when writing hs-err reports, but it is also used in low level utility functions like `os::print_hex_dump()` and `os::is_readable_pointer()`. It is also used (JDK-8282306) as part of call stack printing. At the moment it is implemented via dynamically generated stub routines. That has disadvantages:

1) on Mac m1, it causes problems with execution prevention for generated code, requiring awkward - and partly nonfunctional - workarounds like this: https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/hotspot/share/runtime/safefetch.inline.hpp#L37-L41 . Partly nonfunctional since this requires Thread::current() to be present, which cannot be guaranteed for all call sites of SafeFetch().

2) Since SafeFetch relies on dynamic stub generation, there is a time window during VM initialization where SafeFetch is unreliable. As a result, hs-err reports for crashes in that time can get compromised. It also may affect early NMT reports, when call stacks are printed.

3) Dynamic generation uses a tiny bit of startup time.

SAP proposed a patch for (1) with JDK-8282475 [2], but the discussion bogged down. Andrew Haley proposed a different approach [2], namely to generate SafeFetch statically. Generating it statically would mean the code lives in the text segment and is not subject to execution prevention, so it would solve (1). It also solves (2) since we generate it at compile time. And we would save a bit of time during VM start. Finally, it would be a good preparation in case other platforms introduce execution prevention mechanics like Mac M1.

I have a prototype that works on Linux (x64, x86, aarch64, arm), MacOS (x64, aarch64), Windows, and Zero. It uses static assembly (MacOS and Linux) resp. SEH (Windows) resp. sigsetjmp/longjmp (zero).

[1] https://github.com/openjdk/jdk/pull/7727
[2] https://github.com/openjdk/jdk/pull/7727#issuecomment-1064936019