[pull] master from ruby:master#90
Merged
pull[bot] merged 10000 commits intoturkdevops:masterfrom Jul 15, 2025
Merged
Conversation
It's only needed if using GCC `ifunc` mecanism, which we don't. ruby/json@d3317b9f82
* ZJIT: Stop tracking EP == BP assumption on JIT entry * Enable test_method.rb as well
otherwise, gcc 15 will complain:
> init.c:573:19: error: too many arguments to function ‘Rconnect’; expected 0, have 3
> 573 | return (VALUE)Rconnect(arg->fd, arg->sockaddr, arg->len);
> | ^~~~~~~~ ~~~~~~~
> In file included from init.c:11:
> rubysocket.h:294:5: note: declared here
> 294 | int Rconnect();
> | ^~~~~~~~
> sockssocket.c:33:9: error: too many arguments to function ‘SOCKSinit’; expected 0, have 1
> 33 | SOCKSinit("ruby");
> | ^~~~~~~~~ ~~~~~~
> In file included from sockssocket.c:11:
> rubysocket.h:293:6: note: declared here
> 293 | void SOCKSinit();
> | ^~~~~~~~~
Signed-off-by: Z. Liu <zhixu.liu@gmail.com>
In C99, a function declaration with an empty argument list means "no information about the arguments", not "it takes no arguments" - the so-called old K&R style.
I plan to introduce a `base_system_gems` helper to actually install gems from `base_system_gem_path` into system gems but that would collapse with an existing helper. ruby/rubygems@714c209e62
…onger needs realworld gems ruby/rubygems@9cf284997b
…d the gem installed The deprecation message is printed regardless. ruby/rubygems@397999a390
I spent quite a while on this and I have not been able to reproduce or even understand how the original issue would happen. I also suspect it never actually reproduced the original problem properly. Since I'm in the middle of migrating all specs away from touching the network, I decided to remove it since I can't write an equivalent spec without being able to understand the original problem. ruby/rubygems@c9dfa20877
Optparse was vendored a while ago. ruby/rubygems@d7afd43756
…s with latest versions ruby/rubygems@9da44ade24
Also removed the helper to install real gems during specs to avoid the temptation of introducing network stuff again. ruby/rubygems@a1ab5e319a
I don't think it makes sense to make this tiny behavior change configurable. If someone wants to parse version output, and we have a public setting, they are going to need to accommodate their regexps to both values of the setting. In addition to this, I plan to enhance version output with a note about "simulated version", and in that case, "print_only_version_number" would no longer hold, since what we print will be more than that anyways. So, I'd like to remove the setting and change the output in Bundler 4 with no way to opt out. ruby/rubygems@d84e9dcf09
We have a quality spec that parses all code for explicit usages of `Bundler.settings[<something>`, to detect undocumented settings. So using `Bundler.settings` consistently will help catching these things. ruby/rubygems@ce01bb7cc5
This is not currently causing any issues, but I think the most correct thing to do is that Bundler loads the extensions to RubyGems in the first place, so that they are available from the beginning. ruby/rubygems@88faa5c7bb
If you abort running test suite with a quick double Ctrl-C, tmp files will be left around, and they will interfere with the next test run. To avoid this, make sure to clear them once at the beginning of the test suite. ### Before ``` $ bin/parallel_rspec 16 processes for 175 specs, ~ 11 specs per process .............................................................................................^C^C Finished in 19.45 seconds (files took 0.42722 seconds to load) 94 examples, 0 failures (... turbo tests backtrace ...) $ bin/parallel_rspec 16 processes for 175 specs, ~ 11 specs per process .F....F....F...F......^C Failures: (... failures' details ...) ``` ### After ``` $ bin/parallel_rspec 16 processes for 175 specs, ~ 11 specs per process .................................................................................^C^C Finished in 18.18 seconds (files took 0.4383 seconds to load) 82 examples, 0 failures (... turbo tests backtrace ...) $ bin/parallel_rspec 16 processes for 175 specs, ~ 11 specs per process ................................................................................^C^C Finished in 8.79 seconds (files took 0.45187 seconds to load) 80 examples, 0 failures (... turbo tests backtrace ...) ``` ruby/rubygems@6767a52711
…s before 2.6.2 RubyGems generated binstubs still provide support for this ancient version. This makes no sense since we prevent downgrades to such old versions. ruby/rubygems@089cdc3b77
…RubyGems We'll want to reuse this helper in other situations where we don't want all Bundler loaded. ruby/rubygems@9e7018b0a1
…Bundler We were only avoiding them when the RUBYGEMS_GEMDEPS variable is used. Avoid the warnings in general, whenever the entrypoint to Bundler is `require`. ruby/rubygems@8683faef36
…atest RubyGems Also fix platform warnings when Bundler's entrypoint is bundler's binstub. ruby/rubygems@4b1df58403
These are instance methods, not class methods. And `URI::Parser` was moved to URI::RFC2396_Parser at [r46491] [r46491]: bb83f32dc3e0 ruby/uri@452d74390c
For the references to URI::RFC2396_Parser private methods. ruby/uri@372fbb455d
Co-authored-by: Alan Wu <alansi.xingwu@shopify.com> Co-authored-by: Stan Lo <stan.lo@shopify.com>
Some GC modules, notably MMTk, support parallel GC, i.e. multiple GC threads work in parallel during a GC. Currently, when two GC threads scan two iseq objects simultaneously when YJIT is enabled, both threads will attempt to borrow `CodeBlock::mem_block`, which will result in panic. This commit makes one part of the change. We now set the YJIT code memory to writable in bulk before the reference-updating phase, and reset it to executable in bulk after the reference-updating phase. Previously, YJIT lazily sets memory pages writable while updating object references embedded in JIT-compiled machine code, and sets the memory back to executable by calling `mark_all_executable`. This approach is inherently unfriendly to parallel GC because (1) it borrows `CodeBlock::mem_block`, and (2) it sets the whole `CodeBlock` as executable which races with other GC threads that are updating other iseq objects. It also has performance overhead due to the frequent invocation of system calls. We now set the permission of all the code memory in bulk before and after the reference updating phase. Multiple GC threads can now perform raw memory writes in parallel. We should also see performance improvement during moving GC because of the reduced number of `mprotect` system calls.
This is the second part of making YJIT work with parallel GC. During GC, `rb_yjit_iseq_mark` and `rb_yjit_iseq_update_references` need to resolve offsets in `Block::gc_obj_offsets` into absolute addresses before reading or updating the fields. This needs the base address stored in `VirtualMemory::region_start` which was previously behind a `RefCell`. When multiple GC threads scan multiple iseq simultaneously (which is possible for some GC modules such as MMTk), it will panic because the `RefCell` is already borrowed. We notice that some fields of `VirtualMemory`, such as `region_start`, are never modified once `VirtualMemory` is constructed. We change the type of the field `CodeBlock::mem_block` from `Rc<RefCell<T>>` to `Rc<T>`, and push the `RefCell` into `VirtualMemory`. We extract mutable fields of `VirtualMemory` into a dedicated struct `VirtualMemoryMut`, and store them in a field `VirtualMemory::mutable` which is a `RefCell<VirtualMemoryMut>`. After this change, methods that access immutable fields in `VirtualMemory`, particularly `base_ptr()` which reads `region_start`, will no longer need to borrow any `RefCell`. Methods that access mutable fields will need to borrow `VirtualMemory::mutable`, but the number of borrowing operations becomes strictly fewer than before because borrowing operations previously done in callers (such as `CodeBlock::write_mem`) are moved into methods of `VirtualMemory` (such as `VirtualMemory::write_bytes`).
Print the filename, line number, and whether or not the function has been optimized: ``` Initial HIR: fn initialize@test.rb:4: bb0(v0:BasicObject): v2:Fixnum[1] = Const Value(1) SetIvar v0, :@A, v2 Return v2 Optimized HIR: fn initialize@test.rb:4: bb0(v0:BasicObject): v2:Fixnum[1] = Const Value(1) SetIvar v0, :@A, v2 Return v2 ```
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )