RFR: 8359827: Test runtime/Thread/ThreadCountLimit.java should run exclusively [v3]

[David Holmes]

On Mon, 21 Jul 2025 09:17:32 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test runtime/Thread/ThreadCountLimit.java was observed fails when run with other tests. The test start subprocess with [shell prefix command](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java#L82) `ulimit -u 4096` which intend to limite the usage of thread number. But this will cause test fails when this test run with other tests. I create a demo to demonstrate that.
>> 
>> I start a java process which will create 5k threads, and then I can not start new java process with prefix `ulimit -u 4096` on the same machine.
>> 
>> <img width="1573" height="182" alt="image" src="https://github.com/user-attachments/assets/8dd53ade-cad7-4a2f-b5d9-d4b2d200b728" />
>> 
>> 
>> [ManyThreads.java.txt](https://github.com/user-attachments/files/21324354/ManyThreads.java.txt)
>> 
>> So it's necessary to make this test run sperately to make this test success.
>> Change has been verified locally, test-fix only, risk is low.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mv test/hotspot/jtreg/runtime/Thread/stress/ThreadCountLimit.java test/hotspot/jtreg/resourcehogs/runtime/Thread/

There is definitely something unexpected/odd about the behaviour of `ulimit` when used in this way, though I do not observe the exact problems you describe unless I run a number of test processes concurrently - which is simply demonstrating machine overloading.

First, what does it even mean to use `ulimit -u`? The manpage says it limits the maximum number of processes  the user can create - it doesn't say "per shell" (and `setrlimit` confirms this). But you can easily demonstrate that the user can create far more processes/threads than have been set by a `ulimit` command running in another shell. So perhaps there is something else that affects how `ulimit` works, and that something is different between our systems and yours. ?? (I know there are capabilities that disable the limit but I couldn't see any indication such capabilities were present.)

Second, I observe that with `ulimit -u 1024` I can't even run `java-version` - which makes no sense in terms of number of threads created. Relatedly with a 4096 limit the test typically can only create around 2500 threads - so where did the other 1500+ go?

The use of `ulimit` was added to the test, for Linux only, because we found we could exhaust other resources that could then cause fatal errors in the VM in unexpected places - rather than the failure of `pthread_create` that we were trying to induce.

I'm really not sure how to proceed here. The change you propose affects all platforms, but there is only an issue for you on Linux.

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

PR Comment: https://git.openjdk.org/jdk/pull/26401#issuecomment-3101109747