RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v4]

[Johan Sjölen]

On Thu, 18 Sep 2025 00:12:20 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Well, that was a very embarrassing bug :-). I had code in an `assert` which needed to run regardless if in a debug build or not. Why didn't all release builds fail? No clue.
>
>> I had code in an `assert` which needed to run regardless if in a debug build or not. Why didn't all release builds fail? No clue.
> 
> The GHA teir1 testing on static JDK is only enabled for release builds currently. We haven't setup testing on debug builds for static JDK due to resource limit in GHA build environment. @magicus and the build team have solution(s) to address the issue with https://bugs.openjdk.org/browse/JDK-8350450.

> > Hi @jianglizhou ,
> > There's a test failure that only appears in linux-x64-static tier1. I'm looking at running the tests under the static-jdk. So far, I've produced a static-jdk via `make CONF=slow static-jdk-image`. Do you happen to know how to execute the tier1 tests with such a JDK?
> > I've tried `make JDK_UNDER_TEST=build/linux-x64-slowdebug/images/static-jdk/ test TEST=tier1` but it complains about JDK_UNDER_TEST not being a non-control variable.
> 
> Hi @jdksjolen, to run jtreg tests on a `static-jdk` binary, you can set `JDK_FOR_COMPILE=<static_jdk>`, `JDK_FOR_COMPILE=<regular-jdk-path>` and `extra-problem-lists` options in jtreg command line. The GHA testing on static JDK setup those to run tier1 tests:
> 
> https://github.com/openjdk/jdk/blob/aa36799acb5834d730400fb073a9a3a8ee3c28ef/.github/workflows/test.yml#L185
> 
> https://bugs.openjdk.org/browse/JDK-8303796?focusedId=14745789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14745789 has a command line example for running tier1 tests on static-jdk.
> 
> To build a static JDK: `make static-jdk-image`.
> 
> Hope those are helpful.

Thank you for your help!

I did something akin to this, and it worked:


$ make CONF=linux-x64 static-jdk-image
$ make CONF=linux-x64 jdk-image
$ make CONF=linux-x64 JDK_FOR_COMPILE='/home/jsjolen/jdk/build/linux-x64/images/jdk/' JDK_UNDER_TEST=/home/jsjolen/jdk/build/linux-x64/images/static-jdk/ test TEST='jtreg:runtime/NMT/ThreadedVirtualAllocTestType.java'


This did reproduce the test failure on linux-x64-static :-).


> The changes in `VMATree::copy_into` of this PR, are only seen if we test/check the allocation_sites after a baseline. As I checked the gTest/JTREG tests, none of them check the sites that is written out to the report. So, the code for `copy_into` is never run in release builds and no allocation_site will be stored in a baseline nor written out in the report. No test will check it to discover it.

The test `ThreadedVirtualAllocTestType` does run NMT under detailed mode and was tested in release for all platforms. This was the one that failed in linux-x64-static. The weird thing is that the test succeeded in all other release platforms, even though they should have had the same assert problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/27170#issuecomment-3306388800