RFR: 8320534: fatal error for the NMTBenchmark test run for the mainline build

[Thomas Stuefe]

On Wed, 6 Mar 2024 13:13:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> @afshin-zafari Still unclear, sorry. Since there is no bug analysis on the issue, could you explain what the bug is, what causes the memory corruption, and how your patch fixes it?
>> 
>> The benchmark (like any other jmh benchmark) can be run from command line. In command line it is possible to set the number of threads that concurrently run every test (method of a Java class) inside the benchmark. In this benchmark, every method creates and manages the threads itself. Simply, there is a THREADS parameter inside the benchmark which accepts values of `{1,2,4,8}` where 1 means single threaded. There is also possible to set the NO-OF-THREADS thru the command line. So, when the benchmark supposed to run with 1 thread but externally the NO-OF-THREADS set to 1+, the program crashes or memory is not safely/correctly shared between threads.
>> The fix here, reads the NO-OF-THREADS cmd-line arg  and if it is not 1, exits the benchmark by throwing an exception.
>
>> > @afshin-zafari Still unclear, sorry. Since there is no bug analysis on the issue, could you explain what the bug is, what causes the memory corruption, and how your patch fixes it?
>> 
>> The benchmark (like any other jmh benchmark) can be run from command line. In command line it is possible to set the number of threads that concurrently run every test (method of a Java class) inside the benchmark. In this benchmark, every method creates and manages the threads itself. Simply, there is a THREADS parameter inside the benchmark which accepts values of `{1,2,4,8}` where 1 means single threaded. There is also possible to set the NO-OF-THREADS thru the command line. So, when the benchmark supposed to run with 1 thread but externally the NO-OF-THREADS set to 1+, the program crashes or memory is not safely/correctly shared between threads. The fix here, reads the NO-OF-THREADS cmd-line arg and if it is not 1, exits the benchmark by throwing an exception.
> 
> Sorry, not clear. The thread argument mechanic is, but not why we crash. I would like to prevent this error from being hidden instead of solved, therefore I would like to understand why we crash.
> 
> The benchmark calls whitebox APIs, right? Which call os::reserve, os::commit, etc? None of which should be having problems with being called from multiple threads. None of which should result in an overwritten malloc header that in turn crashes the JVM.

> @tstuefe, do you have any further comments on this?

So the problem is not the invocation of os::malloc, etc, which should be threadsafe? The problem is that we share a single address array across multiple threads in the java part of the benchmark?

If so, okay. I like @xmas92 proposal, if that is possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/17824#issuecomment-1994009962