Skip to content

Conversation

@pull
Copy link

@pull pull bot commented Nov 4, 2025

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

luke-gruber and others added 7 commits November 3, 2025 14:30
We can avoid taking this barrier if we're not incremental marking or lazy sweeping.
I found this was taking a significant amount of samples when profiling `Psych.load`
in multiple ractors due to the vm barrier. With this change, we get significant improvements
in ractor benchmarks that allocate lots of objects.

-- Psych.load benchmark --

```
Before:            After:
r:   itr:   time   r:   itr:   time
0    #1:  960ms    0    #1:  943ms
0    #2:  979ms    0    #2:  939ms
0    #3:  968ms    0    #3:  948ms
0    #4:  963ms    0    #4:  946ms
0    #5:  964ms    0    #5:  944ms
1    #1:  947ms    1    #1:  940ms
1    #2:  950ms    1    #2:  947ms
1    #3:  962ms    1    #3:  950ms
1    #4:  947ms    1    #4:  945ms
1    #5:  947ms    1    #5:  943ms
2    #1: 1131ms    2    #1: 1005ms
2    #2: 1153ms    2    #2:  996ms
2    #3: 1155ms    2    #3: 1003ms
2    #4: 1205ms    2    #4: 1012ms
2    #5: 1179ms    2    #5: 1012ms
4    #1: 1555ms    4    #1: 1209ms
4    #2: 1509ms    4    #2: 1244ms
4    #3: 1529ms    4    #3: 1254ms
4    #4: 1512ms    4    #4: 1267ms
4    #5: 1513ms    4    #5: 1245ms
6    #1: 2122ms    6    #1: 1584ms
6    #2: 2080ms    6    #2: 1532ms
6    #3: 2079ms    6    #3: 1476ms
6    #4: 2021ms    6    #4: 1463ms
6    #5: 1999ms    6    #5: 1461ms
8    #1: 2741ms    8    #1: 1630ms
8    #2: 2711ms    8    #2: 1632ms
8    #3: 2688ms    8    #3: 1654ms
8    #4: 2641ms    8    #4: 1684ms
8    #5: 2656ms    8    #5: 1752ms
```
)

These just call to the C functions that do the optimized test but this avoids the side exit.

See #12123 for the original CRuby/YJIT implementation.
Inline the `String#bytesize` function and remove the C call.
…when building gems

In general, rubygems should provide mechanism and not policy.

Pessimistic versioning is not universally better, and in many
cases, it can cause more problems than it solves. Rubygems should
not be warning against open-ended versioning when building gems.
The majority of the default gems with dependencies do not use
pessimistic versioning, which indicates that Ruby itself
recognizes that open-ended versioning is generally better.

In some cases, depending on a prerelease gem is the only choice
other than not releasing a gem. If you are building an extension
gem for a feature in a prerelease version of another gem, then
depending on the prerelease version is the only way to ensure
a compatible dependency is installed.

ruby/rubygems@beba8dd065
I would like to use the tar implementation inside a Ractor, but two of
the constants are not frozen.  This patch freezes the constants so we
can use it in a Ractor.

ruby/rubygems@0ff4790f4c
@pull pull bot locked and limited conversation to collaborators Nov 4, 2025
@pull pull bot added the ⤵️ pull label Nov 4, 2025
@pull pull bot merged commit 0d210f4 into turkdevops:master Nov 4, 2025
1 of 2 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants