GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||
GeezerVison is showing github.com — Allow using vthreads for all Ruby threads by headius · Pull Request #9789 · jruby/jruby Conversation
|
|
Surprisingly, making all threads be vthreads did not break a single test. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
69a6490 to
de85fd4
Compare
|
I have switched the feature off for now and it can be safely merged any time. We will want to do more experimentation, and perhaps add a JRuby-specific enhancement to allow opting-in for specific threads (e.g. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
de85fd4 to
51a13a0
Compare
|
I had the logic flipped, actually. Most builds fail with all threads virtual because virtual threads do not appear to be setting up the RubyThreadGroup correctly. I've flipped it back on with corrected logic to try to get things green. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I threw Codex at this to work out edge cases and explore possible issues for users: PR #9789: additional changes and user effectsAdditional changes
Likely user effects when enabled
With the default setting, Ruby-created threads remain platform-backed; fiber configuration remains independent. References |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Ruby threads have been normal native threads up to now. This patch allows opting into using virtual threads for Ruby threads, in a model closer to m:n threading. New property: jruby.thread.vthread=(true/*false)
bb81299 to
32aadbc
Compare
|
I squashed the relevant changes and pushed a new commit that enables vthreads to shake out more problems. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Replace the regression test's fixed default assumption and repeated startup program with JRuby-specific behavior examples in explicitly configured fresh JVMs. Cover backing identity, lifecycle, priority inheritance and deferred interrupt delivery independently of the parent suite's thread mode.
Run native process waits on platform workers while preserving errno and interrupt handling on the Ruby caller. Park fiber creators until their backing thread is adopted instead of repeatedly yielding. Cover process status, detach, errno and concurrent fiber results in fresh JVMs with explicitly enabled and disabled virtual Ruby threads and bounded carrier pools.
|
Lots of brute-force testing here so I've mostly been letting agents do it. Additional fixes are coming. This won't be enabled by default, but I'm trying to shake out as many issues with the vthread mode as possible. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Use the same intrinsic monitor for all weak subclass-set operations. A parkable lock can unmount a waiter that later needs a carrier while other threads pin all carriers under the hierarchy monitor. Preserve mutual exclusion for weak-map cleanup during reads. Existing class-concurrency coverage passes repeated bounded-carrier controls and MRI Class/Module tests in both Ruby thread backing modes.
Scheduler close can resume fibers and wait for them. Holding the thread monitor pins JDK 21 carriers during this handoff and can prevent the fibers from ever running. Guard disposal entry separately and publish completion after scheduler close, keeping scheduler joiners blocked until teardown is complete. Finish cleanup in a finally block without suppressing callback errors. Add fresh-JVM coverage for scheduler shutdown with explicit virtual and platform Ruby threads. The enabled case detects the old deadlock with a single carrier; the disabled control passes.
Restore the fiberBlock parameter name used by upstream frame cloning. The merge retained the old block parameter, duplicating the local block variable and leaving fiberBlock undefined, so all JRuby builds failed. Keep both per-fiber frame cloning and the CompletableFuture startup handoff from the virtual-thread fixes.
Release the channel blocking monitor across selector waits and restore its original blocking mode only after the final concurrent selector is deregistered. Run blocking Java selector calls on platform workers for virtual Ruby threads, keeping Ruby event polling and cleanup on the caller. Cover concurrent accepts, targeted interruption, server reuse and closing pending acceptors in fresh JVMs with explicit backing modes.
Preserve shared-channel selection and virtual-thread selector offloading while taking currentSelector away under its wakeup lock before pooling. Retain upstream monitor wakeups and monotonic thread-join behavior.
|
There's a lot of changes that still need to be reviewed. A few quick ones:
|
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.