Fix excessive invalidation for opt_getinlinecache

YJIT expects the VM to invalidate opt_getinlinecache when updating the
constant cache, and the invalidation used to happen even when YJIT can't
use the cached value.

Once the first invalidation happens, the block for opt_getinlinecache
becomes a stub. When the stub is hit, YJIT fails to compile the
instruction as the cache is not usable. The stub becomes a block that
exits for opt_getinlinecache which can be invalidated again. Some
workloads that bust the interpreter's constant cache can create an
invalidation loop with this behavior.

Check if the cache is usable become doing invalidation to fix this
problem.

In the test harness, evaluate the test script in a lambda instead of a
proc so `return` doesn't return out of the harness.

1 files changed, 9 insertions, 1 deletions

diff --git a/yjit_iface.c b/yjit_iface.c
index 0f11fa61a5..18f35f576d 100644
--- a/yjit_iface.c
+++ b/yjit_iface.c
@@ -597,10 +597,18 @@ rb_yjit_constant_state_changed(void)
     }
 }
 
-// Callback from the opt_setinlinecache instruction in the interpreter
+// Callback from the opt_setinlinecache instruction in the interpreter.
+// Invalidate the block for the matching opt_getinlinecache so it could regenerate code
+// using the new value in the constant cache.
 void
 yjit_constant_ic_update(const rb_iseq_t *iseq, IC ic)
 {
+    // We can't generate code in these situations, so no need to invalidate.
+    // See gen_opt_getinlinecache.
+    if (ic->entry->ic_cref || rb_multi_ractor_p()) {
+        return;
+    }
+
     RB_VM_LOCK_ENTER();
     rb_vm_barrier(); // Stop other ractors since we are going to patch machine code.
     {