On Wed, 20 May 2026 15:06:55 GMT, Aleksey Shipilev <[email protected]> wrote:
>> We were already seeing some issues on mac when the test was added, and it >> was therefor disabled on those platforms. Now we've had reports that this >> test is causing OOMs on other systems as well. >> >> Rather than outright removing the test, I've detuned it to create less >> thread/memory churn, more in line with other tests. >> >> Since The test has been detuned, it no longer needs to be in it's own test >> group, and can safely run as part of the regular `jdk_foreign` tests. I've >> changed the jtreg test groups to reflect this. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > test/jdk/java/foreign/TestUpcallStress.java line 70: > >> 68: @BeforeClass >> 69: public void setup() { >> 70: executor = Executors.newFixedThreadPool(THREAD_COUNT); > > Do you really want 100 threads on all systems? Or do you want `NCPU` threads, > but at least 100 tasks? The failure mode that the test was added for was a race between multiple threads trying to initialize the `vmtarget` of a lambda form wrapped by the MethodHandle that is the target of an upcall stub. I found in my testing that more congestion helps give a better chance that multiple threads end up racing to prepare the same lambda form, presumably because one of them gets de-scheduled in the middle of it, giving another thread a chance to see the un-prepared LF, and try to initialize it as well (this process is racy, and multiple threads may end up writing a result). In other words, the goal with using 100 threads is to create congestion for the scheduler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31216#discussion_r3276302678
