RFR: JDK-8319828: runtime/NMT/VirtualAllocCommitMerge.java may fail if mixing interpreted and compiled native invocations [v3]

[Thomas Stuefe]

> 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.
> 
> 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 how 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 was done interpreted, the second one compiled. Therefore we run with different stacks, one with an interpreter codelet, one with an nmethod. Can be easily reproduced on x64, see 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 fix is to just run everything interpreted. I don't want to just define compilation for NMTCommitMemory(), since the compiled vs interpreted question may affect other stack frames as well. Best to have stable stack frames for this test.

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

  fix comment tag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16583/files
  - new: https://git.openjdk.org/jdk/pull/16583/files/8b9739fb..20e3e844

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16583&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16583&range=01-02

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

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