[pull] master from ruby:master - #1392
Merged
Merged
Conversation
Much like `opt_getconstant_path`, check the cache and see if the
interpreter has done the hard work for us already. If it has, just
re-use the result.
For example, support regexp modifier `o` , which runs the code to
create the regular expression... once:
```ruby
def test = /#{'a'.upcase}/o
```
ISEQ_TRANSLATED is defined through a chain of macros that ends in an enum value (IMEMO_FL_USER3 -> FL_USER8 -> RUBY_FL_USER8), which bindgen cannot evaluate, so YJIT and ZJIT had been defining the constant manually in cruby.rs. ZJIT doesn't even use the constant, so drop it there, and re-expose it for YJIT through enum yjit_bindgen_constants in yjit.c so that the Rust side can no longer go out of sync with iseq.h. #18597 (comment)
gc_clock_start/end read CLOCK_PROCESS_CPUTIME_ID, which is the sum of every thread's cpu time. A local GC runs while the other Ractors keep going, so their work is counted as collection: the same ten collections of the same objects in one Ractor are reported as 3ms alone and 146ms with eight unrelated busy Ractors -- 96% of the wall clock that Ractor ran in, and in another run more than the wall clock. Read the collecting thread's own cpu instead. A local GC runs to its end on one thread, and a global one stops the others, so this is what the number was always meant to be. With the fix the same measurement reads 3 / 4 / 6 / 18ms, the remaining growth being collections that genuinely cost more on a busy machine. The read also gets cheaper. GC.measure_total_time is on by default, so every program pays for four of these reads per collection, and neither cpu clock is served by the vDSO: both are real syscalls. Reading CLOCK_PROCESS_CPUTIME_ID makes the kernel walk every thread in the process, so it costs 477ns with one thread and 3.6us with 256, while CLOCK_THREAD_CPUTIME_ID is 454ns whatever the count (idle Ryzen 9 8945HS; the threads were asleep, they only have to exist, not run). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
OpenBSD CI now runs inside a qemu virtual machine inside a Ubuntu virtual machine, without hardware virtualization support. It is limited to 2.5GB of RAM and only 2 vCPUs. There is a bootstrap test that fails on it due to resource issues. ``` bootstraptest.test_ractor.rb_1536_1361.rb:8:in 'Thread#initialize': can't create Thread: Cannot allocate memory (ThreadError) ``` Fix this by using 100 threads instead of 1000.
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
5 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] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )