RFR: 8309698: [S390X] Test hotspot/jtreg/runtime/NMT/VirtualAllocCommitMerge.java fails after JDK-8299089

[Thomas Stuefe]

On Thu, 11 Jul 2024 08:18:00 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> I can reproduce it on `jdk11u-dev` head as well. So I guess this is coming from far back than that commit.

Huh that's weird. Is this a particular hardware configuration that is new, or a new compiler? Because I am sure we do s390 tests. I think Adoptium does too.

What happens:

We use NativeCallStack to get a stack at the point os::commit_memory is called:

https://github.com/openjdk/jdk/blob/2928753bd95356467e4fe42ee391e45d1cb6e89c/src/hotspot/share/runtime/os.cpp#L2117

CALLER_PC resolves to NativeCallStack(1), which walks the stack starting one frame above. If that fails, the stack will have 0 in its first slot (https://github.com/openjdk/jdk/blob/2928753bd95356467e4fe42ee391e45d1cb6e89c/src/hotspot/share/utilities/nativeCallStack.hpp#L59) and printing will stop right away (https://github.com/openjdk/jdk/blob/2928753bd95356467e4fe42ee391e45d1cb6e89c/src/hotspot/share/nmt/memReporter.cpp#L427-L432).

But according to the printout, there is no general problem with stack printing, since I see call stacks ending in os::commit_memory (see the many "committed xxx from").

In this case, the stack should show the whitebox function `WB_NMTCommitMemory` which calls `os::commit_memory()` (https://github.com/openjdk/jdk/blob/62cbf70346e78ca94ce6ea4ba5a308ea0a2bbfa8/src/hotspot/share/prims/whitebox.cpp#L715-L718)

So, the task would be to find out whats so special about this function that it does not show up in the callstack.

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

PR Comment: https://git.openjdk.org/jdk/pull/20096#issuecomment-2222346556