8000 Use vthreads when available by headius · Pull Request #7328 · jruby/jruby · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Use vthreads when available #7328

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 29, 2022
Merged

Conversation

headius
Copy link
Member
@headius headius commented Aug 26, 2022

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

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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0