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

[SendaoYan]

On Tue, 22 Jul 2025 05:28:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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.

Hi @dholmes-ora 

> which is simply demonstrating machine overloading.

I think it's not machine overloading, becasuse the setting of 'ulimit -u' on my machine is 'unlimited'. I can create 5000 threads many times, show as below:

<img width="1013" height="811" alt="image" src="https://github.com/user-attachments/assets/9bee9870-d13c-4e00-b9c8-d2ad6813aa0f" />

> 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

I think the 'ulimit -u' in sub-shell take effect in the sub-shell only, it's temporary setting, it will not affect the parent shell.

> Relatedly with a 4096 limit the test typically can only create around 2500 threads - so where did the other 1500+ go?

It seems that the sub-shell with 'ulimit -u 4096' prefix will count all the user processes number. It's just my speculatation.


Anyway, I change this PR to use `docker run --pids-limit 4096` to instead the original 'ulimit -u 4096'. It will make this test more complict but more elegant.

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

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