The interpreter instruction count was enabled based on RUBY_DEBUG as
opposed to YJIT_STATS. In builds with YJIT_STATS=1 but RUBY_DEBUG=0,
the count was not available.
Move YJIT_STATS in yjit.h where declarations are expoed to code outside
of YJIT. Also reduce the changes made to the interpreter for calling
into YJIT's instruction counting function.
We need to fire the write barrier during ivar set. This function
extracts the write barrier function then calls it.
Co-Authored-By: John Hawthorn <john@hawthorn.email>
We have a check to ensure we don't have to push args on the stack to
call a cfunc with many args. However we never need to use the stack for
variadic cfuncs, so we shouldn't care about the number of arguments.
The code path for leave that returns to the interpreter
(gen_leave() -> yjit_gen_leave_exit()) used to have the logic:
```
cfp->sp++;
cfp->sp[-1] = return_val;
cfp->sp--;
return return_val;
```
The SP changes it made was unnecessary and this change removes it.
After this change, `leave` doesn't adjust the `cfp->sp` of the caller
and only writes `cfp->sp[0]`. To accomodate this in the JIT-to-JIT
return case, return stubs have an `sp_offset` of 1.
The change removes sp adjustment from the JIT-to-JIT return case, too,
making it more efficient. Also, since the C method case of `send`
has an `sp_offset` of 1 after the call, this change enables block
version sharing.
Previously checktype only supported heap objects, however it's not
uncommon to receive an immediate, for example when string interpolating
a Symbol or Integer.
We should only clear the JIT function when the entry point is
invalidated. Right now we only support compiling functions with a PC
offset of zero (functions that take optional parameters can start at
non-zero PC), so this patch just checks that the index is 0 before
clearing the jit function
For use cases where you want to collect the metrics
for a specific piece of code (typically a web request)
you can have the stats turned off by default and then
turn them on at runtime before executing the code you care
about.
This change fixes some cases where YJIT fails to fire tracing events.
Most of the situations YJIT did not handle correctly involves enabling
tracing while running inside generated code.
A new operation to invalidate all generated code is added, which uses
patching to make generated code exit at the next VM instruction
boundary. A new routine called `jit_prepare_routine_call()` is
introduced to facilitate this and should be used when generating code
that could allocate, or could otherwise use `RB_VM_LOCK_ENTER()`.
The `c_return` event is fired in the middle of an instruction as opposed
to at an instruction boundary, so it requires special handling. C method
call return points are patched to go to a fucntion which does everything
the interpreter does, including firing the `c_return` event. The
generated code for C method calls normally does not fire the event.
Invalided code should not change after patching so the exits are not
clobbered. A new variable is introduced to track the region of code that
should not change.
RUBY_DEBUG have a very significant performance overhead. Enough that
YJIT with RUBY_DEBUG is noticeably slower than the interpreter without
RUBY_DEBUG.
This makes it hard to collect yjit-stats in production environments.
By allowing to collect JIT statistics without the RUBy_DEBUG overhead,
I hope to make such use cases smoother.
The FIXME is there so we remember to investigate why insns clears the
temporary array. Is this necessary? If it's not we can remove it from
both.
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
Previously all stack operands would become unknown once the stack grew
beyond a certain size. This worked, but unnecessarily hid available
information.
If we hit this at PC > 0 (ie. with an optional argument) the provided
types and context are likely incorrect and it is likely this block can't
be used.
