If all nodes in the array are safe, then it is safe to avoid
allocation for the positional splat:
```ruby
m(*a, kw: [:a]) # Safe
m(*a, kw: [meth]) # Unsafe
```
This avoids an unnecessary allocation in a Rails method call.
Details: https://github.com/rails/rails/pull/54949/files#r2052645431
This was handled correctly in parse.y (NODE_COLON2), but not in
prism. This wasn't caught earlier, because I only added tests for
the optimized case and not the unoptimized case. Add tests for
the unoptimized case.
In code terms:
```ruby
m(*a, kw: lvar::X) # Does not require allocation for *a
m(*a, kw: method()::X) # Requires allocation for *a
```
This commit fixes the second case when prism is used.
Add methods for setting supported signature algorithms, corresponding
to SSL_CTX_set1_sigalgs_list() and SSL_CTX_set1_client_sigalgs_list(),
respectively.
6bbe58c492
Co-authored-by: Markus Jung <markus.jung@vivavis.com>
Currently to test Bundler 3 mode we have to actually edit the version
file to simulate we're running a future version. This is inconvenient.
Instead, allow passing an environment variable, `BUNDLER_3_MODE`, to set
the "working mode" Bundler should use.
This can now be set easily by end users to enable them to try out the
changes in the future version and give us feedback.
It's unclear how version auto-switching should work when this
environment variable is set, so the auto-switching feature will be
disabled in that case.
4e92e9b209
* `invokebuiltin`
* `invokebuiltin_delegate`
* `invokebuiltin_delegate_leave`
These instructions all call out to a C function, passing EC, self, and
some number of arguments. `invokebuiltin` gets the arguments from the
stack, whereas the `_delegate` instructions use a subset of the locals.
`opt_invokebuiltin_delegate_leave` has a fast path for `leave`, but I'm
not sure we need to do anything special for that here (FWIW YJIT appears
to treat the two delegate instructions the same).
Followup: https://github.com/ruby/ruby/pull/13589
This simplify a lot of things, as we no longer need to manually
manage the memory, we can use the Read-Copy-Update pattern and
avoid numerous race conditions.
Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>
Issue a call to rb_vm_opt_getconstant_path() like the interpreter, but
since that allocates the IC, we need to save the PC before calling. Add
FrameState to GetConstPath to get access to the PC.
* `opt_hash_freeze`
* `opt_ary_freeze`
* `opt_str_freeze`
* `opt_str_uminus`
Similar to `opt_neq`, but there are no args for `freeze`
Co-authored-by: ywenc <ywenc@github.com>
Co-authored-by: Max Bernstein <max@bernsteinbear.com>
If a previous copy of a gem is already installed, RubyGems will not
reinstall the gem but only recompile its extensions. This seems like a
good idea, but only if the gem is being installed from the registry.
If we are installing a locally built package, then the package should be
completely reinstalled and extensions compiled from the sources in the
locally built package, not from the sources in the previous
installation.
1c282d98d5
The `source` field in IO::Buffer can have a String or an IO::Buffer
object, if not nil.
- When the `source` is a String object. The `base` field points to the
memory location of the String content, which can be embedded in
RSTRING, and in that case, GC compaction can move the memory region
along with the String object.
Thus, IO::Buffer needs to pin the `source` object to prevent `base`
pointer from becoming invalid.
- When the `source` is an IO::Buffer, then `base` is a pointer to a
malloced or mmapped memory region, managed by the source IO::Buffer.
In this case, we don't need to pin the source IO::Buffer object,
since the referred memory region won't get moved by GC.
Closes: [Bug #21210]
Prior to this commit we compiled `putstring` and `putchilledstring` to
`StringCopy`, but then failed to compile past HIR.
This commit adds codegen for `StringCopy` to call `rb_ec_str_ressurrect`
as the VM does for these instructions.
* ZJIT: Add support for putspecialobject
* Address feedback
* Update tests
* Adjust the indentation of a Ruby test
---------
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
Issue - https://bugs.ruby-lang.org/issues/21436
Apparently, the lower bound check is missing, which results in overflow & wrapping later on in RB_INT2FIX
Signed-off-by: Dmitry Dygalo <dmitry.dygalo@workato.com>
67d75e8423
[Bug #21438]
Previously GC could trigger a table rebuild of the generic fields
st_table in the middle of calling the st_update callback. This could
cause entries to be reallocated or rearranged and the update to be for
the wrong entry.
This commit adds an assertion to make that case easier to detect, and
replaces the st_update with a separate st_lookup and st_insert.
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
Co-authored-by: Jean Boussier <byroot@ruby-lang.org>
This test was written for another implementation of `#object_id`
which had complex interations with GC, that's not the case of
the implementation that was actually merged.
* Add `open_timeout` as an overall timeout option for `Socket.tcp`
[Background]
Currently, `TCPSocket.new` and `Socket.tcp` accept two kind of timeout options:
- `resolv_timeout`, which controls the timeout for DNS resolution
- `connect_timeout`, which controls the timeout for the connection attempt
With the introduction of Happy Eyeballs Version 2 (as per [RFC 8305](https://datatracker.ietf.org/doc/html/rfc8305)) in[ Feature #20108](https://bugs.ruby-lang.org/issues/20108) and [Feature #20782](https://bugs.ruby-lang.org/issues/20782), both address resolution and connection attempts are now parallelized.
As a result, the sum of `resolv_timeout` and `connect_timeout` no longer represents the total timeout duration. This is because, in HEv2, name resolution and connection attempts are performed concurrently, causing the two timeouts to overlap.
Example:
When `resolv_timeout: 200ms` and `connect_timeout: 100ms` are set:
1. An IPv6 address is resolved after the method starts immediately (IPv4 is still being resolved).
2. A connection attempt is initiated to the IPv6 address
3. After 100ms, `connect_timeout` is exceeded. However, since `resolv_timeout` still has 100ms left, the IPv4 resolution continues.
4. After 200ms from the start, the method raises a `resolv_timeout` error.
In this case, the total elapsed time before a timeout is 200ms, not the expected 300ms (100ms + 200ms).
Furthermore, in HEv2, connection attempts are also parallelized.
It starts a new connection attempts every 250ms for resolved addresses. This makes the definition of `connect_timeout` even more ambiguous—specifically, it becomes unclear from which point the timeout is counted.
Additionally, these methods initiate new connection attempts every 250ms (Connection Attempt Delay) for each candidate address, thereby parallelizing connection attempts. However, this behavior makes it unclear from which point in time the connect_timeout is actually measured.
Currently, a `connect_timeout` is raised only after the last connection attempt exceeds the timeout.
Example:
When `connect_timeout: 100ms` is set and 3 address candidates:
1. Start a connection attempt to the address `a`
2. 250ms after step 1, start a new connection attempt to the address `b`
3. 500ms after step 1, start a new connection attempt to the address `c`
4. 1000ms after step 3 (1000ms after starting the connection to `c`, 1250ms after starting the connection to `b,` and 1500ms after starting the connection to `a`) `connect_timeout` is raised
This behavior aims to favor successful connections by allowing more time for each attempt, but it results in a timeout model that is difficult to reason about.
These methods have supported `resolv_timeout` and `connect_timeout` options even before the introduction of HEv2. However, in many use cases, it would be more convenient if a timeout occurred after a specified duration from the start of the method. Similar functions in other languages (such as PHP, Python, and Go) typically allow specifying only an overall timeout.
[Proposal]
I propose adding an `open_timeout` option to `Socket.tcp` in this PR, which triggers a timeout after a specified duration has elapsed from the start of the method.
The name `open_timeout` aligns with the existing accessor used in `Net::HTTP`.
If `open_timeout` is specified together with `resolv_timeout` and `connect_timeout`, I propose that only `open_timeout` be used and the others be ignored. While it is possible to support combinations of `open_timeout`, `resolv_timeout`, and `connect_timeout`, doing so would require defining which timeout takes precedence in which situations. In this case, I believe it is more valuable to keep the behavior simple and easy to understand, rather than supporting more complex use cases.
If this proposal is accepted, I also plan to extend `open_timeout` support to `TCPSocket.new`.
While the long-term future of `resolv_timeout` and `connect_timeout` may warrant further discussion, I believe the immediate priority is to offer a straightforward way to specify an overall timeout.
[Outcome]
If `open_timeout` is also supported by `TCPSocket.new`, users would be able to manage total connection timeouts directly in `Net::HTTP#connect` without relying on `Timeout.timeout`.
aa0f689bf4/lib/net/http.rb (L1657)
---
* Raise an exception if it is specified together with other timeout options
> If open_timeout is specified together with resolv_timeout and connect_timeout, I propose that only open_timeout be used and the others be ignored.
Since this approach may be unclear to users, I’ve decided to explicitly raise an `ArgumentError` if these options are specified together.
* Add doc
* Fix: open_timeout error should be raised even if there are still addresses that have not been tried
If an object is shareable and has no capacity left, it isn't
safe to store the object ID in fields as it requires an object
resize which can't be done unless all field reads are synchronized.
In this very specific case we create the object_id in advance,
before the object is made shareable.
[Bug #21439] Fix PM_SPLAT_NODE compilation error in for loops
This commit fixes a crash that occurred when using splat nodes (*) as
the index variable in for loops. The error "Unexpected node type for
index in for node: PM_SPLAT_NODE" was thrown because the compiler
didn't know how to handle splat nodes in this context.
The fix allows code like `for *x in [[1,2], [3,4]]` to compile and
execute correctly, where the splat collects each sub-array.
Now that class fields have been deletated to a T_IMEMO/class_fields
when we're in multi-ractor mode, we can read and write class instance
variable in an atomic way using Read-Copy-Update (RCU).
Note when in multi-ractor mode, we always use RCU. In theory
we don't need to, instead if we ensured the field is written
before the shape is updated it would be safe.
Benchmark:
```ruby
Warning[:experimental] = false
class Foo
@foo = 1
@bar = 2
@baz = 3
@egg = 4
@spam = 5
class << self
attr_reader :foo, :bar, :baz, :egg, :spam
end
end
ractors = 8.times.map do
Ractor.new do
1_000_000.times do
Foo.bar + Foo.baz * Foo.egg - Foo.spam
end
end
end
if Ractor.method_defined?(:value)
ractors.each(&:value)
else
ractors.each(&:take)
end
```
This branch vs Ruby 3.4:
```bash
$ hyperfine -w 1 'ruby --disable-all ../test.rb' './miniruby ../test.rb'
Benchmark 1: ruby --disable-all ../test.rb
Time (mean ± σ): 3.162 s ± 0.071 s [User: 2.783 s, System: 10.809 s]
Range (min … max): 3.093 s … 3.337 s 10 runs
Benchmark 2: ./miniruby ../test.rb
Time (mean ± σ): 208.7 ms ± 4.6 ms [User: 889.7 ms, System: 6.9 ms]
Range (min … max): 202.8 ms … 222.0 ms 14 runs
Summary
./miniruby ../test.rb ran
15.15 ± 0.47 times faster than ruby --disable-all ../test.rb
```
If `gem pristine foo` is run, and there's a default copy of foo, only
executables for it are reset. However, that was causing other copies of
`foo` to only reset executables, which is unexpected.
We should not modify `options[:only_executables]`, but respect its value
for every gem, and make sure special handling for default gems does not
leak to other gems.
2c3039f1b0
