| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
* YJIT: Add codegen for Integer methods
* YJIT: Update dependencies
* YJIT: Fix Integer#[] for argc=2
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
* YJIT: Rest and keyword (non-supplying)
* Update yjit/src/codegen.rs
---------
Co-authored-by: Maxime Chevalier-Boisvert <maximechevalierb@gmail.com>
|
| |
|
| |
|
|
|
|
|
| |
* Use shape information in YJIT's definedivar implementation
* Handle complex shape for definedivar
|
|
|
|
|
|
|
|
|
|
|
|
| |
We crashed in some edge cases due to the recent change to not compile
encoded iseqs that are larger than `u16::MAX`.
- Match the C signature of rb_yjit_constant_ic_update() and clamp down
to `IseqIdx` size
- Return failure instead of panicking with `unwrap()` in codegen when
the iseq is too large
Co-authored-by: Maxime Chevalier-Boisvert <maxime.chevalierboisvert@shopify.com>
Co-authored-by: Noah Gibbs <noah.gibbs@shopify.com>
|
|
|
|
|
|
|
| |
So by itself, this shouldn't have been a correctness issue, but we
also pop the stack for block_args. Doing stack manipulation like that
and then side-exiting causes issues. So, while this fixes the
immediate failure, we have a bigger issue with block_args popping and
then exiting that we need to deal with.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 5d0a1ffafa61da04dbda38a5cb5565bcb8032a78.
This commit is causing sequel in yjit-bench to raise with this stack trace:
```
sequel-5.64.0/lib/sequel/dataset/sql.rb:266:in `literal': wrong argument type Array (expected Proc) (TypeError)
from sequel-5.64.0/lib/sequel/database/misc.rb:269:in `literal'
from sequel-5.64.0/lib/sequel/adapters/shared/sqlite.rb:314:in `column_definition_default_sql'
from sequel-5.64.0/lib/sequel/database/schema_methods.rb:564:in `block in column_definition_sql'
from sequel-5.64.0/lib/sequel/database/schema_methods.rb:564:in `each'
from sequel-5.64.0/lib/sequel/database/schema_methods.rb:564:in `column_definition_sql'
from sequel-5.64.0/lib/sequel/database/schema_methods.rb:634:in `block in column_list_sql'
from sequel-5.64.0/lib/sequel/database/schema_methods.rb:634:in `map'
from sequel-5.64.0/lib/sequel/database/schema_methods.rb:634:in `column_list_sql'
from sequel-5.64.0/lib/sequel/database/schema_methods.rb:753:in `create_table_sql'
from sequel-5.64.0/lib/sequel/adapters/shared/sqlite.rb:348:in `create_table_sql'
from sequel-5.64.0/lib/sequel/database/schema_methods.rb:702:in `create_table_from_generator'
from sequel-5.64.0/lib/sequel/database/schema_methods.rb:203:in `create_table'
from benchmarks/sequel/benchmark.rb:19:in `<main>'
```
|
|
|
|
| |
../bootstraptest/runner.rb:121: warning: assigned but unused variable - e
|
|
|
|
|
|
|
|
|
| |
* YJIT: Rest and block_arg support
* Update bootstraptest/test_yjit.rb
---------
Co-authored-by: Maxime Chevalier-Boisvert <maximechevalierb@gmail.com>
|
| |
|
| |
|
|
|
|
|
| |
`*pcnt++` just dereferences `pcnt` then increments the local variable,
but has no side effect.
|
|
|
|
| |
and unskip a ractor test that was actually running
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you have a method that takes rest arguments and a splat call that
happens to line up perfectly with that rest, you can just dupe the
array rather than move anything around. We still have to dupe, because
people could have a custom to_a method or something like that which
means it is hard to guarantee we have exclusive access to that array.
Example:
```ruby
def foo(a, b, *rest)
end
foo(1, 2, *[3, 4])
```
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Ractor should take care method cache invalidation.
Added test will miss method cache on each method call.
|
|
|
|
| |
This reverts commit 8d31a60f47fb053bcfe0c744a89bd666dae48539.
|
|
|
|
|
| |
This should be enough for `make test` and `make btest-ruby` while it
doesn't work for `make btest`.
|
|
|
|
|
| |
Includes small reproduction produced by Kokubun.
http://ci.rvm.jp/results/trunk-yjit@ruby-sp2-docker
|
|
|
|
|
| |
https://github.com/ruby/ruby/actions/runs/4316423442/jobs/7532190115
http://ci.rvm.jp/results/trunk-yjit@ruby-sp2-docker/4466770
|
|
|
|
|
|
| |
This reverts commit 9792d9e40f790e6deb18ead56a8befc9d5c4bc51.
Ractor implementation has been rewritten. Let's see if it works now.
|
|
|
| |
Follow-up for cb8a040b7906c09d9d3ac3d3fe853f633005024f.
|
|
|
|
|
|
| |
It returns the waiting set is empty or not.
Also add Ractor::Selector's tests.
|
|
|
|
| |
I hope a4421bd73c286253311c2cdf8c78ed258f8cff44 will solve the issue...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch rewrites Ractor synchronization mechanism, send/receive
and take/yield.
* API
* Ractor::Selector is introduced for lightweight waiting
for many ractors.
* Data structure
* remove `struct rb_ractor_waiting_list` and use
`struct rb_ractor_queue takers_queue` to manage takers.
* remove `rb_ractor_t::yield_atexit` and use
`rb_ractor_t::sync::will_basket::type` to check the will.
* add `rb_ractor_basket::p.take` to represent a taking ractor.
* Synchronization protocol
* For the Ractor local GC, `take` can not make a copy object
directly so ask to generate the copy from the yielding ractor.
* The following steps shows what `r1.take` does on `r0`.
* step1: (r0) register `r0` into `r1`'s takers.
* step2: (r0) check `r1`'s status and wakeup r0 if `r1` is waiting
for yielding a value.
* step3: (r0) sleep until `r1` wakes up `r0`.
* The following steps shows what `Ractor.yield(v)` on `r1`.
* step1: (r1) check first takers of `r1` and if there is (`r0`),
make a copy object of `v` and pass it to `r0` and
wakes up `r0`.
* step2: (r1) if there is no taker ractors, sleep until
another ractor try to take.
|
|
|
|
|
|
|
|
|
|
| |
Related to:
https://github.com/ruby/ruby/pull/7377
Previously it was believed that there was a problem with a combination
of cfuncs + splat + send, but it turns out the same issue happened
without send. For example `Integer.sqrt(1, *[])`. The issue was
happened not because of send, but because of setting the wrong argc
when we don't need to splat any args.
|
|
|
|
|
|
|
|
|
|
| |
`make test-spec` revealed this issue after applying an unrelated bug
fix. A crashing case is included, though I suspect there are other
scenarios where it misbehaves. Don't compile for now.
Note that this is *not* an issue on the 3.2.x series; it has
`send_args_splat_non_iseq` which already rejects all splats to cfuncs,
including sends with splats.
|
|
|
|
| |
Co-authored-by: Maxime Chevalier-Boisvert <maxime.chevalierboisvert@shopify.com>
Co-authored-by: Alan Wu <XrXr@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
| |
Support invokesuper in a block on YJIT
invokesuper previously side exited when it is in a block. To make sure we're compiling the correct method in super, we now use the local environment pointer (LEP) to get the method, which will work in a block.
Co-authored-by: John Hawthorn <john@hawthorn.email>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
are exiting (#6929)
YJIT: Implement splat for cfuncs. Split exit cases
This also implements a new check for ruby2keywords as the last
argument of a splat. This does mean that we generate more code, but in
actual benchmarks where we gained speed from this (binarytrees) I
don't see any significant slow down. I did have to struggle here with
the register allocator to find code that didn't allocate too many
registers. It's a bit hard when everything is implicit. But I think I
got to the minimal amount of copying and stuff given our current
allocation strategy.
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 650a20a3e1205f47224a987676cdbad7d826d597.
Now that 3.2.0 is released, let's disable flaky tests. Koichi said he'll
rework Ractor implementation for this, and it has not been done yet.
|
|
|
|
|
|
|
|
|
|
| |
I noticed this while running test_yjit with --mjit-call-threshold=1,
which redefines `Integer#<`. When Ruby is monkey-patched,
MJIT itself could be broken.
Similarly, Ruby scripts could break MJIT in many different ways. I
prepared the same set of hooks as YJIT so that we could possibly
override it and disable it on those moments. Every constant under
RubyVM::MJIT is private and thus it's an unsupported behavior though.
|
| |
|
|
|
|
|
|
| |
This would be still flaky, but we want to make sure there's no
YJIT-specific issue when Ruby 3.2 is released. We might skip it again
after the release.
|
|
|
|
|
| |
This reduces global lock acquiring for reading.
https://bugs.ruby-lang.org/issues/18949
|
| |
|
| |
|
|
|
|
|
| |
Koichi plans to rework Ractor implementation to address these failures.
He agreed to skip flaky Ractor tests for now.
|