RFR: JDK-8304815: Use NMT for more precise hs_err location printing [v6]

[Thomas Stuefe]

> (This is a byproduct of work on the arm port for https://github.com/openjdk/jdk/pull/10907. I needed better debugging information in the hs-err file and in gdb.)
> 
> Back in 2022 @zhengyu123 had the very nice idea of using NMT mapping info for smartening up pp in gdb: [JDK-8280289](https://bugs.openjdk.org/browse/JDK-8280289).
> 
> The same idea can be applied to hs_err file location printing. NMT has information about all its mappings and can tell us where it thinks a given unknown pointer points into.
> 
> This could be even more useful if the "find malloc block" part of that functionality would be smarter. As it is now, it only works if the pointer in question points to the start of a user-allocated area. Would be nice if the code could (carefully) search for the next valid-looking malloc header instead.
> 
> --------------
> 
> This patch does this: we introduce a new API, MemTracker::print_containing_region(void*), that tries to make sense of a given unknown pointer.
> 
> It will search its mmap regions and print those if found. For malloc'ed pointers, it will carefully sniff out the immediate surroundings of the block, trying to find what looks like a valid malloc header. It uses SafeFetch to not trip over unmapped or protected pages. Note that, of course, we may get false recognition positives if it finds something that looks like a valid header. But even that could be useful (e.g. a remnant dead header may indicate we access memory after free).
> 
> Looks like this (its arm, so 32-bit pointers):
> 
> 
> Register to memory mapping:
> 
> ->  r0  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
> ->  r1  = 0x75b02010 into life malloced block starting at 0x75b02010, size 184, tag mtObjectMonitor
> ->  r2  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r3  = 0x0 is nullptr
> ->  r4  = 0x728a6ae0 into life malloced block starting at 0x728a6ae0, size 104, tag mtSynchronizer
>     r5  = 0xb6d3bbc8: <offset 0x018f6bc8> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     r6  = 0xffffffff is an unknown value
>     r7  = 0x0 is nullptr
>     r8  = 0x0000000a is an unknown value
>     r9  = 0x728a4308 is a thread
>     r10 = 0x0000000b is an unknown value
> ->  fp  = 0x753fe8cc in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     r12 = 0x0 is nullptr
> ->  sp  = 0x753fe8b0 in mmap'd memory region [0x75380000 - 0x75400000] by Thread Stack
>     lr  = 0xb69bc1d0: <offset 0x015771d0> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
>     pc  = 0xb69c8670: <offset 0x01583670> in /shared/projects/openjdk/jdk-jdk/output-fastdebug-arm/images/jdk/lib/server/libjvm.so at 0xb5445000
> 
> 
> 
> The small caveat here is that NMT reporting needs ThreadCritical, and thus using it for location printing may block error reporting if it crashed inside a ThreadCritical section. We face the same issue today when printing the NMT report as part of the hs-err file. 
> 
> I think the usefulness of these printouts justify this risk. However I opened https://bugs.openjdk.org/browse/JDK-8304824 to investigate a better locking strategy for NMT.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  fix comment, update copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13162/files
  - new: https://git.openjdk.org/jdk/pull/13162/files/07d70fd9..e5a4a9f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13162&range=04-05

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13162.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13162/head:pull/13162

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