YJIT: avoid using deferred compilation if context already has the type info we need

[maximecb]

At the moment, we often use deferred compilation to peek at a value on the stack, or to peek at self (see jit_peek_at_stack and jit_peek_at_self). The downside of that is that it breaks blocks into smaller parts. That adds overhead, increases JIT memory usage, and also potentially takes away some optimization opportunities, because our backend is looking at smaller blocks with less opportunities to do peephole optimizations.

I was thinking that in some cases, the context may already have the type information we're looking for. We might already know the type of the value we want to peek at. If that's true, then we could avoid doing deferred compilation in order to peek at value type(s). If we can improve our type tracking (see #460 for example) the need to do deferred compilation might decrease over time as well.

A good first step may be to check how often we actually know all the types we need and may be able to avoid doing deferred compilation. If we choose to go forward, this can also be broken into multiple PRs if it's easier.

Aaron has expressed interest in taking this first issue. I was thinking it might make sense for him to pair with the amazing @jhawthorn if he's available, since John has already made multiple improvements to the type information tracking in the context.

[maximecb]

Alan points out that: for method calls, which is probably the most common reason we defer, we need the exact class of the receiver to lookup the method, setup assumptions etc. We can never get that info from the context because we never store it. Another major source of defer are constants, and we need to lift from the interpreter's cache for those.

I think we may still be able to avoid deferred compilation for fixnum cases and array accesses, but those might be relatively infrequent compared to method calls and getivar/setivar.

This might be more motivation to work on a more sophisticated context object. We might want work on a more sophisticated context object to take priority over this issue.

[k0kubun]

Alan points out that: for method calls, which is probably the most common reason we defer
Another major source of defer are constants
I think we may still be able to avoid deferred compilation for fixnum cases and array accesses, but those might be relatively infrequent compared to method calls and getivar/setivar.

I just counted the defer frequency for each case on railsbench with 959579d:

defer_count: 6789
defer_send_general: 4563
defer_setinstancevariable: 496
defer_opt_getconstant_path: 466
defer_getinstancevariable: 462
defer_opt_aref: 379
defer_objtostring: 202
defer_invokesuper: 169
defer_opt_eq: 147
defer_opt_aset: 140
defer_getblockparamproxy: 69
defer_invokeblock: 47
defer_opt_plus: 43
defer_fixnum_cmp: 26
defer_opt_mod: 14
defer_opt_minus: 11
defer_opt_case_dispatch: 10
defer_opt_and: 8
defer_opt_or: 3

Given that compiled_block_count is 20461 and for the reason pointed out above, the impact we can make here might be a bit limited.

[maximecb]

I think that's true for now, and definitely not worth trying to push this for 3.2, but ideally, if we can start storing known shapes in the context next year, we could do something with this idea.

[maximecb]

Update: @tenderlove and @jemmaissroff intend to explore tracking the shape of self in the context which ties into this idea.

One metric I would like to see them track is how tracking the shape of self affects the frequency of deferred compilation. Reducing it by a meaningful percentage could be a positive impact on our ability to have larger blocks for optimization.

[k0kubun]

defer_send_general: 4563
defer_setinstancevariable: 496
defer_opt_getconstant_path: 466

For those insns, looking at a runtime value may not be the only motivation for defer_compilation. By splitting a block with it, we also make the block more useful for chain guards. If we don't split a block there, chain guards for a single place might run more duplicated code, and constant update may invalidate more code.

I guess the ideal behavior would be to not split a block when the callsite is monomorphic, and split it afterwards when it becomes polymorphic. Same applies to jump_to_next_insn + EndBlock. But we'd have to complicate implementation for saving memory that way.

[maximecb]

Going to close this issue since it's not super specific.

We're going to want to revisit this topic once we can track the class/shape of self in the context.