A question I have for the future: how hard is it to synthesize a CALL_DATA? If we're going to be turning this call to :new into a call to :initialize, the call to :initialize has to come from somewhere. I suppose we could try and keep track of the optimized "inlined" :initialize call from the opt_new compiler output, but that seems brittle. We'll probably also want to do more of this kind of stuff in the future unrelated to what's in the bytecode.

A question I have for the future: how hard is it to synthesize a CALL_DATA? If we're going to be turning this call to :new into a call to :initialize, the call to :initialize has to come from somewhere. I suppose we could try and keep track of the optimized "inlined" :initialize call from the opt_new compiler output, but that seems brittle.

You'll need to discover an existing cc in the ISEQ to avoid extra allocation, and the same applies to ci when it has keyword arguments. And the cd itself should also be fetched from the bytecode to avoid consuming extra memory. Basically, we should not synthesize a cd but just discover it since the ISEQ already has one and we don't want to waste memory for JIT.

Since the bytecode has send instructions that call into .new and #initialize, we'll need to discover those instructions. I'm not sure what kind of algorithm we need to discover them, but if it's too hard, we could modify the interpreter to let the interpreter and ZJIT agree on where to find the instructions.