Alan Wu

Yeah. I haven't thought too deeply about this, but I think making each `using` call site good for one use cuts off most exploits and makes the system give feedback...

Seems like in all the larger benchmarks the benefits from skipping gets washed out by the checks basically randomly falling on either side, making it hard for the branch predictor....

It looks intentional that the place could only have Qfalse or an imemo, so `nil` shouldn't be there. If perf hit is insignificant we could make the `VM_CHECK_MODE` assertions unconditional,...

Yeah, it's just too hard/incompatible to change at this point. And not much to gain from it.

I wrote a patch that pins the objects that are in the st_table rather than the original object by allocating a separate too-complex T_OBJECT as the pinner. No need for...

I don't like forcing everyone to shrink-on-freeze either. It's expectation defying and a subtle, possibly breaking change. The worst kind of breaking change. See also: https://github.com/ruby/ruby/pull/11103#issuecomment-2208349628

> Is it? That seems even more expectation defying. I can easily explain to someone "when you freeze an array, it gets right sized", versus "your frozen array will get...

Please make a ticket about changing `OBJ_FREEZE` if you want to proceed. This is a breaking change that deserves to be broadcasted on the mailing list. Your ticket doesn't mention...

Yes, you should make clear that the new function you add is a YJIT helper and by not putting it in headers, express that it has many preconditions that are...

> Initially Aaron had reported a big speedup on protoboeuf with your original patch. ... I don't fully understand why the original patch had such a big speedup in the...