We switch to a new page when we detect dropped_bytes flipping from false
to true. Previously, when we patch code for invalidation during code gc,
we start with the flag being set to true, so we failed to apply patches
that straddle pages. We would write out jumps half way and then stop,
which left the code corrupted.
Reset the flag before patching so we patch across pages properly.
Preivously we didn't have a "checking ...." line for this check and when
rustc was too old, we would dump the error message to the console like:
checking for rustc... rustc
error: there is no argument named `x`
--> <anon>:1:33
|
1 | fn main() { let x = 1; format!("{x}"); }
| ^^^
error: aborting due to previous error
`configure` checks usually don't do this and this might be confusing.
With this commit it now says something like:
checking whether rustc is new enough for YJIT... no
This dispatches to a c func for doing the dynamic lookup. I experimented with chain on the proc but wasn't able to detect which call sites would be monomorphic vs polymorphic. There is definitely room for optimization here, but it does reduce exits.
[Bug #19105]
If no fiber scheduler is registered and the fiber that
owns the lock and the one that try to acquire it
both belong to the same thread, we're in a deadlock case.
Co-authored-by: Jean Boussier <byroot@ruby-lang.org>
GCC [Bug 99578] seems triggered by calling `rb_reg_last_match` before
`match_check(match)`, probably by `NIL_P(match)` in `rb_reg_nth_match`.
[Bug 99578]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
`throw TAG_BREAK` instruction makes a jump only if the continuation of
catch of TAG_BREAK exactly matches the instruction immediately following
the "send" instruction that is currently being executed. Otherwise, it
seems to determine break from proc-closure.
Branch coverage may insert some recording instructions after "send"
instruction, which broke the conditions for TAG_BREAK to work properly.
This change forces to set the continuation of catch of TAG_BREAK
immediately after "send" (or "invokesuper") instruction.
[Bug #18991]
There are a few downsides of the current approach:
1. Because gem specs are lazily retrieved, this computation happens in
every irb completion test case, which is not necessary. (In tests we
don't cache the result of `retrieve_files_to_require_from_load_path`)
2. Gem::Specification.latest_specs is sensible to the content of
LOAD_PATH. And when combined with 1, tests fail "randomly" if they
try to mutate LOAD_PATH, even though the test subject it's something
else.
So by pre-computing and storing the gem paths in a constant, it guarantees
that the computation only happens once and it doesn't get affected by test
cases.
One argument could be made against the change is that, it'll store
unnecessary data for users that disable autocompletion. But the
counter-arguments are:
1. Since autocompletion is enabled by default, this should not be the
case for most users.
2. For users with autocompletion enabled, IRB already caches the
result of `retrieve_files_to_require_from_load_path` in memory, which
should have a similar size of GEM_SPECS. And we currently haven't
received any report about problems caused by such memory consumption.
https://github.com/ruby/irb/commit/c671d39020
fiber machine stack is placed outside of C stack allocated by wasm-ld,
so highest stack address recorded by `rb_wasm_record_stack_base` is
invalid when running on non-main fiber.
Therefore, we should scan `stack_{start,end}` which always point a valid
stack range in any context.
because it's much slower on M1 https://github.com/ruby/erb/pull/29.
It'd be too complicated to switch the implementation based on known
optimized platforms / versions.
Besides, short strings are the most common usages of this method and
SIMD doesn't really help that case. All in all, I can't justify the
existence of this code.
https://github.com/ruby/erb/commit/30691c8995
(https://github.com/ruby/erb/pull/29)
Typically, strpbrk(3) is optimized pretty well with SIMD instructions.
Just using it makes this as fast as a SIMD-based implementation for the
no-escape case.
Not utilizing this for escaped cases because memory allocation would be
a more significant bottleneck for many strings anyway. Also, there'll be
some overhead in calling a C function (strpbrk) many times because we're
not using SIMD instructions directly. So using strpbrk all the time
might not necessarily be faster.
Nobuyoshi Nakada
Yusuke Endoh
Alan Wu
Jimmy Miller
Matt Valentine-House
Takashi Kokubun
Stan Lo
Bo Anderson
Maxime Chevalier-Boisvert
Jean byroot Boussier
git
yui-knk
Peter Zhu
Benoit Daloze
Yuta Saito