Skip to content

Use vthreads when available#7328

Merged
headius merged 1 commit intojruby:jruby-9.3from
headius:vthread_fibers
Aug 29, 2022
Merged

Use vthreads when available#7328
headius merged 1 commit intojruby:jruby-9.3from
headius:vthread_fibers

Conversation

@headius
Copy link
Member

@headius headius commented Aug 26, 2022 •
edited
Loading

Virtual threads from Project Loom allow spinning up many more fibers than when using native threads. This is an early patch to add vthread support to JRuby's fibers when the vthread API is available (starting as a preview feature in JDK19).

Enable the feature when running on JDK 19:

  • Pass --enable-preview to the JVM
  • Pass -J--enable-preview to JRuby
  • Put --enable-preview in JAVA_OPTS env

Tested with 100k fibers spun up, and then later resumed, using the following script:

5.times do
  t = Time.now

  # create 100k fibers
  ary = 100_000.times.map { Fiber.new { } }

  # resume and complete 100k fibers
  ary.each(&:resume)

  p Time.now - t
end

Without vthreads, this script runs for a few seconds and then blows up, either raising memory errors or crashing the JVM. With vthreads it can complete multiple iterations, warming up to around 0.7s per loop on my system.

@headius headius added this to the JRuby 9.3.8.0 milestone Aug 26, 2022
@headius
Use vthreads when available
da656aa 
Virtual threads from Project Loom allow spinning up many more
fibers than when using native threads. This is an early patch to
add vthread support to JRuby's fibers when the vthread API is
available (starting as a preview feature in JDK19). Pass
--enable-preview to the JVM to enable vthreads on JDK19.
@headius
Copy link
Member Author

headius commented Aug 29, 2022

Going to land this to start letting folks preview virtual threads once 9.3.8.0 is out. A more elaborate implementation, possibly using executors to schedule fibers within a given thread, can come in 9.4 or after.

@headius headius merged commit e401535 into jruby:jruby-9.3 Aug 29, 2022
@headius headius deleted the vthread_fibers branch August 29, 2022 20:54
@eregon
Copy link
Member

eregon commented Jan 25, 2023 •
edited
Loading

I've been thinking about this.
Is it correct to just use a VirtualThread instead of a Thread for Fibers?

My concern is AFAIK VirtualThreads automatically switch on blocking IO and blocking synchronization calls.
Given that the typical approach to avoid having two Fibers running at the same time (when implemented on top of threads) is to use locks or queues, it sounds like VirtualThreads might switch to another VirtualThread/Fiber unexpectedly.
Although maybe such Fibers would also be blocked anyway if all Fibers of a Ruby Thread wait on the same lock/queue?

Also if the current Fiber's VirtualThread gets blocked on some IO, and the same happens for the current Fiber of another RubyThread they might switch carrier threads I suppose. Not a problem from the Thread.currentThread() POV, but if there is anything native (e.g. a pthread_mutex via FFI) it could matter.

And of course there is the question of how much overhead it is to use locks/queues to make VirtualThread behave like coroutine vs using JDK Continuation (which might not be accessible though) and switching explicitly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

JRuby 9.3.8.0

Development

Successfully merging this pull request may close these issues.

2 participants

@headius @eregon