ZJIT: Recompile ISEQ when a shape check fails on monomorphic callsites

[k0kubun]

context: #771 (comment)

There are phase changes where a reasonable call-threshold setting would not observe all possible types. To address exits in such situations, it's nice to experiment with recompiling a whole ISEQ:

1. Update the profile on such a exit
2. Clear JIT code and reset the call counter to re-compile the ISEQ after profiling num-profiles times again

[aidenfoxivey]

Does a phase change refer to a change in the type or shape of a given variable?

[k0kubun]

Yeah. In production contexts, I would imagine traffic pattern changes over time impact what endpoints are used, which would subsequently shift these things in the application. For ruby-bench, it would be Ruby prelude, ruby-bench harness, benchmark setup, and then benchmark iterations. Each phase of them may change how a method is used with what type/shape.

[k0kubun]

Send/ivar turns out to be a bit complicated because they're compiled as if it was monomorphic even when it's actually (skewed) polymorphic. So it's not guaranteed that the type distribution changes when you profile types at their exits.

I'll land the recompilation support for patch points first. I'll then separately expand its support to send/ivar, changing how polymorphic callsites are compiled. I may work on compiling polymorphic callsites into proper HIR first if needed.

[tekknolagi]

So as we have the JIT right now, recompilation will lead to fewer side exits but it will also make all paths through JIT code slower since we don't handle polymorphic lookup right now.

[tekknolagi]

That is, unless you're clearing previous profiles and starting from a clean slate

[k0kubun]

I'll see what the benchmark results look like. Whether it has a slowdown or not, I'm thinking of compiling a polymorphic callsite as dispatch chains ordered by the distribution + a fallback and the end instead of a side exit, similarly to YJIT. That way, types observed in the past should still be optimized while it doesn't exit.

[k0kubun]

Currently waiting for ruby#15459 to be reviewed

[k0kubun]

So I have a recompile prototype that basically eliminates guard_shape_failure exits, which improves ratio_in_zjit. But the performance was not good, so I'm guessing it hurts the performance to stop specializing skewed monomorphic callsites as monomorphic callsites.

I'll see if there's a simple way to generate code that attempts to optimize a callsite like a monomorphic call but fallbacks to the interpreter without exiting, which can be useful for skewed monomorphic callsites.

[tekknolagi]

Or you can do a GetIvarPolymorphic opcode that turns the profile data into a sort of table and calls a C function to interpret that table

[tekknolagi]

Like

VALUE
rb_zjit_getivar_pic(VALUE obj, const zjit_ivar_pic_entry_t *entries, uint32_t num_entries)
{
    shape_id_t obj_shape = rb_obj_shape_id(obj);

    for (uint32_t i = 0; i < num_entries; i++) {
        if (entries[i].shape_id == obj_shape) {
            if (entries[i].ivar_index == ZJIT_ATTR_INDEX_NOT_SET) {
                return Qnil;  // ivar undefined for this shape
            }
            // Use Ruby's ROBJECT_FIELDS which handles embedded vs heap
            return ROBJECT_FIELDS(obj)[entries[i].ivar_index];
        }
    }

    // Shape not in PIC - return Qundef to trigger side-exit
    return Qundef;
}

[k0kubun]

ruby#16589 fixed most of the problem for guard_shape_failure.

Filed #972 and #971 for remaining issues.