Eugh, going to fix some tests...

(It would probably be ideal if this got squashed)

Come to think of it, @k0kubun should I just have it profile at the top of every instruction? It'll only allocate if we actually recorded anything in the interpreter

should I just have it profile at the top of every instruction?

You mean adding a zjit_ variant to every YARV instruction? Also, what made you think of it?

It'll only allocate if we actually recorded anything in the interpreter

My assumption is that just calling a C (Rust) function and retrieving profiling metadata could be non-zero overhead for profiled runs. Remember we weren't even allowed to increment a global counter vm_insns_count on the interpreter on the default build, for example. It's somewhat mitigated by rewriting them back after num-profile cycles, but profiled runs do get slower. At least I don't want to run a profiler on nop instruction (or anything that doesn't need to record anything).

Oh, no, sorry, I mean just in ISEQ->HIR translation. That will cause a read from IseqPayload in HIR creation but no other work (and, in particular, no other work in the interpreter).

Like lift the profile_stack so that it happens once per opcode.

sounds good then :)