We saw this problem on s390x, but it was easy to reproduce on x64.
The test creates adjacent commit sections via NMTCommitMemory(), and then expects them to show up as merged sections in the NMT report.
That sometimes fails, as here:
```
Execution failed: `main' threw exception: java.lang.RuntimeException: '[0x[0]3ff859fc000 - 0x[0]*3ff85a5c000] committed 384KB from.' missing from stdout/stderr
```
and the relevant snippet in the NMT report was:
```
[0x000003ff859fc000 - 0x000003ff85dfc000] reserved 4096KB for Test from
[0x000003ffb4ad2a58] WB_NMTReserveMemory+0xc0
[0x000003ff9bf43344]
[0x000003ff859fc000 - 0x000003ff85a1c000] committed 128KB from
[0x000003ffb4ad288c] WB_NMTCommitMemory+0xc4
[0x000003ff85a1c000 - 0x000003ff85a5c000] committed 256KB from
[0x000003ffb4ad288c] WB_NMTCommitMemory+0xc4
[0x000003ff9bf43344]
```
Note that it shows two adjacent commit sections, one 128k, one 256k, that the test expected to show up as one merged section of 384k.
The reason for this is that the first invocation of NMTCommitMemory happened interpreted, the second one compiled. That alters the stack: in the first case we have an Interpreter Codelet on the stack, in the second case the compiled nmethod. See here an annotated stack:
```
[0x00007fceb0147000 - 0x00007fceb0547000] reserved 4096KB for Test from
[0x00007fcef3beccd5] WB_NMTReserveMemory+0xa5
[0x00007fcedb92bbce]0x00007fcedb92bbce is at code_begin+1806 in an Interpreter codelet
[0x00007fceb0147000 - 0x00007fceb0167000] committed 128KB from
[0x00007fcef3bed098] WB_NMTCommitMemory+0xa8
[0x00007fcedc0901a1]0x00007fcedc0901a1 is at entry_point+225 in (nmethod*)0x00007fcedc08ff10
[0x00007fceb0167000 - 0x00007fceb01a7000] committed 256KB from
[0x00007fcef3bed098] WB_NMTCommitMemory+0xa8
[0x00007fcedb92bbce]0x00007fcedb92bbce is at code_begin+1806 in an Interpreter codelet
```
Since the stacks differ, NMT does not merge the sections. And that is fine; it shouldn't do that. The test should cope somehow.