Benoit Daloze
@eregon.bsky.social
Rubyist, Researcher at Oracle Labs, part of the @GraalVM team, TruffleRuby lead. Expressed opinions are my own.
TruffleRuby is pretty much that, isn't it?
Or do you mean AOT compiling Ruby code to JVM bytecode? That's possible but the performance would likely be pretty bad, not much faster than an interpreter and then no much point to compile the Ruby code as it would mean a bigger native image.
Or do you mean AOT compiling Ruby code to JVM bytecode? That's possible but the performance would likely be pretty bad, not much faster than an interpreter and then no much point to compile the Ruby code as it would mean a bigger native image.
November 14, 2025 at 9:27 AM
TruffleRuby is pretty much that, isn't it?
Or do you mean AOT compiling Ruby code to JVM bytecode? That's possible but the performance would likely be pretty bad, not much faster than an interpreter and then no much point to compile the Ruby code as it would mean a bigger native image.
Or do you mean AOT compiling Ruby code to JVM bytecode? That's possible but the performance would likely be pretty bad, not much faster than an interpreter and then no much point to compile the Ruby code as it would mean a bigger native image.
Right, it was just for curiosity but indeed others might not know that context (still very early, not tested with Ractor much yet)
November 2, 2025 at 6:56 PM
Right, it was just for curiosity but indeed others might not know that context (still very early, not tested with Ractor much yet)
CRuby 3.5 RactorPool + YJIT: 17.2s
CRuby 3.5 RactorPool + ZJIT: 24.8s
(JRuby RactorPool is NG because JRuby doesn't support C extensions, needed by atomic-ruby)
CRuby 3.5 RactorPool + ZJIT: 24.8s
(JRuby RactorPool is NG because JRuby doesn't support C extensions, needed by atomic-ruby)
November 1, 2025 at 8:26 PM
CRuby 3.5 RactorPool + YJIT: 17.2s
CRuby 3.5 RactorPool + ZJIT: 24.8s
(JRuby RactorPool is NG because JRuby doesn't support C extensions, needed by atomic-ruby)
CRuby 3.5 RactorPool + ZJIT: 24.8s
(JRuby RactorPool is NG because JRuby doesn't support C extensions, needed by atomic-ruby)
Fixed and released as 0.1.1.
@dentarg.bsky.social Thanks for trying this!
On my machine for that benchmark with N=10000:
CRuby 3.5 RactorPool: 27s
JRuby 10.0.2 FixedThreadPool: 5.6s (4.8x faster)
TruffleRuby 25.0 RactorPool: 3.7s (~7.3x faster)
TruffleRuby 25.0 FixedThreadPool: 3.7s too
@dentarg.bsky.social Thanks for trying this!
On my machine for that benchmark with N=10000:
CRuby 3.5 RactorPool: 27s
JRuby 10.0.2 FixedThreadPool: 5.6s (4.8x faster)
TruffleRuby 25.0 RactorPool: 3.7s (~7.3x faster)
TruffleRuby 25.0 FixedThreadPool: 3.7s too
November 1, 2025 at 8:17 PM
Fixed and released as 0.1.1.
@dentarg.bsky.social Thanks for trying this!
On my machine for that benchmark with N=10000:
CRuby 3.5 RactorPool: 27s
JRuby 10.0.2 FixedThreadPool: 5.6s (4.8x faster)
TruffleRuby 25.0 RactorPool: 3.7s (~7.3x faster)
TruffleRuby 25.0 FixedThreadPool: 3.7s too
@dentarg.bsky.social Thanks for trying this!
On my machine for that benchmark with N=10000:
CRuby 3.5 RactorPool: 27s
JRuby 10.0.2 FixedThreadPool: 5.6s (4.8x faster)
TruffleRuby 25.0 RactorPool: 3.7s (~7.3x faster)
TruffleRuby 25.0 FixedThreadPool: 3.7s too
Right, I think Atom#swap should make the value shareable before the CAS, otherwise it can leak the same unshareable object between multiple Ractors, i.e. break the Ractor invariant.
October 30, 2025 at 11:10 PM
Right, I think Atom#swap should make the value shareable before the CAS, otherwise it can leak the same unshareable object between multiple Ractors, i.e. break the Ractor invariant.
Would be good to mention that in the README :)
And sorry for the spam, I should have checked more before posting.
And sorry for the spam, I should have checked more before posting.
October 30, 2025 at 9:24 PM
Would be good to mention that in the README :)
And sorry for the spam, I should have checked more before posting.
And sorry for the spam, I should have checked more before posting.
Ah, but it does `make_shareable` on the value, so it's actually safe and fine then: github.com/joshuay03/at...
$ ruby -W0 -ratomic-ruby -e 'A = Atom.new(Object.new); p A.value; Ractor.new { p A.value; p A.value.frozen? }.join'
#<Object:0x00007f6a91e11260>
#<Object:0x00007f6a91e11260>
true
$ ruby -W0 -ratomic-ruby -e 'A = Atom.new(Object.new); p A.value; Ractor.new { p A.value; p A.value.frozen? }.join'
#<Object:0x00007f6a91e11260>
#<Object:0x00007f6a91e11260>
true
October 30, 2025 at 9:23 PM
Ah, but it does `make_shareable` on the value, so it's actually safe and fine then: github.com/joshuay03/at...
$ ruby -W0 -ratomic-ruby -e 'A = Atom.new(Object.new); p A.value; Ractor.new { p A.value; p A.value.frozen? }.join'
#<Object:0x00007f6a91e11260>
#<Object:0x00007f6a91e11260>
true
$ ruby -W0 -ratomic-ruby -e 'A = Atom.new(Object.new); p A.value; Ractor.new { p A.value; p A.value.frozen? }.join'
#<Object:0x00007f6a91e11260>
#<Object:0x00007f6a91e11260>
true
Mmh, actually Atom seems to allow arbitrary objects to be passed between Ractors, that's not safe:
```
ruby -W0 -ratomic-ruby -e 'A = Atom.new(Object.new); p A.value; Ractor.new { p A.value }.join'
#<Object:0x00007f823a2212e0>
#<Object:0x00007f823a2212e0>
```
```
ruby -W0 -ratomic-ruby -e 'A = Atom.new(Object.new); p A.value; Ractor.new { p A.value }.join'
#<Object:0x00007f823a2212e0>
#<Object:0x00007f823a2212e0>
```
October 30, 2025 at 9:20 PM
Mmh, actually Atom seems to allow arbitrary objects to be passed between Ractors, that's not safe:
```
ruby -W0 -ratomic-ruby -e 'A = Atom.new(Object.new); p A.value; Ractor.new { p A.value }.join'
#<Object:0x00007f823a2212e0>
#<Object:0x00007f823a2212e0>
```
```
ruby -W0 -ratomic-ruby -e 'A = Atom.new(Object.new); p A.value; Ractor.new { p A.value }.join'
#<Object:0x00007f823a2212e0>
#<Object:0x00007f823a2212e0>
```
Nice to see a pure-Ruby Ractor pool.
(well, ignoring Atom but that looks safe)
> Currently requires Ruby 3.5
bsky.app/profile/ereg... might help for that :)
I might give it a try to run the ractor-pool tests with that on other Rubies.
(well, ignoring Atom but that looks safe)
> Currently requires Ruby 3.5
bsky.app/profile/ereg... might help for that :)
I might give it a try to run the ractor-pool tests with that on other Rubies.
October 30, 2025 at 9:15 PM
Nice to see a pure-Ruby Ractor pool.
(well, ignoring Atom but that looks safe)
> Currently requires Ruby 3.5
bsky.app/profile/ereg... might help for that :)
I might give it a try to run the ractor-pool tests with that on other Rubies.
(well, ignoring Atom but that looks safe)
> Currently requires Ruby 3.5
bsky.app/profile/ereg... might help for that :)
I might give it a try to run the ractor-pool tests with that on other Rubies.
If you know of any open-source program using Ractors, let me know, I'd be interested to try it with ractor-shim.
October 30, 2025 at 9:01 PM
If you know of any open-source program using Ractors, let me know, I'd be interested to try it with ractor-shim.
This was fun to create, it took me a day to import the Ractor tests, reimplement the harness to run all tests in process instead of one process per test (so all tests run in 5 seconds!), actually reimplement Ractor and make the CI green for all Ruby versions.
October 30, 2025 at 9:01 PM
This was fun to create, it took me a day to import the Ractor tests, reimplement the harness to run all tests in process instead of one process per test (so all tests run in 5 seconds!), actually reimplement Ractor and make the CI green for all Ruby versions.
My main goal is to easily support Ractor on TruffleRuby and JRuby, which already have parallel Threads. It's actually more efficient since there is no need to freeze or copy when passing objects between Threads.
The implementation passes most Ractor tests, see github.com/eregon/racto... for details
The implementation passes most Ractor tests, see github.com/eregon/racto... for details
October 30, 2025 at 9:01 PM
My main goal is to easily support Ractor on TruffleRuby and JRuby, which already have parallel Threads. It's actually more efficient since there is no need to freeze or copy when passing objects between Threads.
The implementation passes most Ractor tests, see github.com/eregon/racto... for details
The implementation passes most Ractor tests, see github.com/eregon/racto... for details
Not a desktop app but this does the tracking across multiple repositories: github.com/truffleruby/...
GitHub - truffleruby/truffleruby-gem-tracker: Tracking the status of CIs testing TruffleRuby
Tracking the status of CIs testing TruffleRuby. Contribute to truffleruby/truffleruby-gem-tracker development by creating an account on GitHub.
github.com
October 29, 2025 at 10:42 PM
Not a desktop app but this does the tracking across multiple repositories: github.com/truffleruby/...
I think only a handful would comment so I don't think it would cause much "spam" in practice. I would think of it as a simple way to gather support from the community. If some people are against they would likely reply too, and the end result would be that the discussion progresses.
October 28, 2025 at 6:55 PM
I think only a handful would comment so I don't think it would cause much "spam" in practice. I would think of it as a simple way to gather support from the community. If some people are against they would likely reply too, and the end result would be that the discussion progresses.
> isn't nice
True but it feels like a recurring situation that most Rubyists are in agreement and yet very few comment on the issue tracker and core committers potentially being unaware of that. I did polls in the past, it's far from perfect but got some idea of who is for/against.
True but it feels like a recurring situation that most Rubyists are in agreement and yet very few comment on the issue tracker and core committers potentially being unaware of that. I did polls in the past, it's far from perfect but got some idea of who is for/against.
October 28, 2025 at 6:55 PM
> isn't nice
True but it feels like a recurring situation that most Rubyists are in agreement and yet very few comment on the issue tracker and core committers potentially being unaware of that. I did polls in the past, it's far from perfect but got some idea of who is for/against.
True but it feels like a recurring situation that most Rubyists are in agreement and yet very few comment on the issue tracker and core committers potentially being unaware of that. I did polls in the past, it's far from perfect but got some idea of who is for/against.
I replied on that issue and added it to the dev meeting: bugs.ruby-lang.org/issues/21647. Maybe we can decide of when to show the chilled string warning by default to make progress 🤞
October 28, 2025 at 6:49 PM
I replied on that issue and added it to the dev meeting: bugs.ruby-lang.org/issues/21647. Maybe we can decide of when to show the chilled string warning by default to make progress 🤞
Nice post. bugs.ruby-lang.org/issues/20205... is unfortunate. I wonder if it'd make sense to suggest in the post that people who want it default share that on the issue.
I don't get the point to jump to 4.0 this year, there seems to be no breaking change and no big feature that is production-ready.
I don't get the point to jump to 4.0 this year, there seems to be no breaking change and no big feature that is production-ready.
October 28, 2025 at 6:37 PM
Nice post. bugs.ruby-lang.org/issues/20205... is unfortunate. I wonder if it'd make sense to suggest in the post that people who want it default share that on the issue.
I don't get the point to jump to 4.0 this year, there seems to be no breaking change and no big feature that is production-ready.
I don't get the point to jump to 4.0 this year, there seems to be no breaking change and no big feature that is production-ready.
Then one could also measure the overhead of freezing/copying easily if there is also a full Ractor implementation that does the freezing/copying.
October 22, 2025 at 4:18 PM
Then one could also measure the overhead of freezing/copying easily if there is also a full Ractor implementation that does the freezing/copying.
I'm thinking it might make sense (for JRuby and TruffleRuby) to have a (pure-Ruby) ractor-shim gem that just uses a Thread per Ractor and makes Ractor.make_shareable a noop, since effectively all objects are shareable between threads. Not sure about Ractor.make_shareable(obj, copy: true) though.
October 22, 2025 at 4:18 PM
I'm thinking it might make sense (for JRuby and TruffleRuby) to have a (pure-Ruby) ractor-shim gem that just uses a Thread per Ractor and makes Ractor.make_shareable a noop, since effectively all objects are shareable between threads. Not sure about Ractor.make_shareable(obj, copy: true) though.
As a note I hadn't seen bsky.app/profile/ruby... yet when reading your post. Finally some concrete factual information from Ruby Central. A bit in a roundabout way but explains some parts of the story.
Here’s a note from our Executive Director regarding our recent security incident.
rubycentral.org/news/rubygem...
rubycentral.org/news/rubygem...
Rubygems.org AWS Root Access Event – September 2025
As part of standard incident-response practice, Ruby Central is publishing the following post-incident review to the public. This document summarizes the September 2025 AWS root-access event, what…
rubycentral.org
October 9, 2025 at 9:39 PM
As a note I hadn't seen bsky.app/profile/ruby... yet when reading your post. Finally some concrete factual information from Ruby Central. A bit in a roundabout way but explains some parts of the story.