ZJIT: Specialize invokeblock for each block_handler type

[k0kubun]

At the moment, invokeblock always resorts to dynamic dispatch, but JIT code can do better.

There are four vm_block_handler_types:

1. block_handler_type_iseq
2. block_handler_type_ifunc
3. block_handler_type_proc
4. block_handler_type_symbol

TODO

• We should profile block_handler on invokeblock and generate specialized code based on compile-time block_handler. It's also nice to have runtime stats to prioritize the most frequent block_handler. YJIT doesn't specialize block_handler_type_proc or block_handler_type_symbol, so majority of them would be block_handler_type_iseq or block_handler_type_ifunc in our benchmarks and production.
  • ZJIT: Profile specific objects for invokeblock ruby/ruby#15051
• If compile-time block_handler is block_handler_type_iseq, you can guard on the expected ISEQ in the block_handler and statically dispatch the callee ISEQ using a JIT-to-JIT call.
• If compile-time block_handler is block_handler_type_ifunc, you can just guard the block_handler type is ifunc (blocks in C), and let rb_vm_yield_with_cfunc call the ifunc.

[tekknolagi]

I think you also mentioned something about a nil block. Where does that come in?

[tekknolagi]

I wonder what percent of time we have a monomorphic target iseq for invokeblock. I'd like to profile that. I will figure out a way to get object profiling into our current setup...

[k0kubun]

I think you also mentioned something about a nil block. Where does that come in?

If a method reaches yield (invokeblock instruction) when the block_handler is not supplied, that'd be an exception. So it's not an optimization target.

Optimizing the &nil block_handler is more relevant in send instructions. It's part of #772.

[tekknolagi]

I made a special kind of ProfiledType that looks at specific objects, not just their classes/shapes (ruby#15051). Then I profiled some of our benchmarks.

For lobsters:

Top-6 invokeblock handler (100.0% of total 1,064,155):
        megamorphic: 494,931 (46.5%)
   monomorphic_iseq: 337,171 (31.7%)
        polymorphic: 113,381 (10.7%)
  monomorphic_ifunc:  52,260 ( 4.9%)
  monomorphic_other:  38,970 ( 3.7%)
        no_profiles:  27,442 ( 2.6%)

For railsbench:

Top-6 invokeblock handler (100.0% of total 2,529,104):
   monomorphic_iseq: 834,452 (33.0%)
        megamorphic: 818,347 (32.4%)
        polymorphic: 632,273 (25.0%)
  monomorphic_ifunc: 224,243 ( 8.9%)
  monomorphic_other:  19,595 ( 0.8%)
        no_profiles:     194 ( 0.0%)

For shipit:

Top-6 invokeblock handler (100.0% of total 2,104,148):
        megamorphic: 1,269,889 (60.4%)
        polymorphic:   411,475 (19.6%)
        no_profiles:   173,367 ( 8.2%)
  monomorphic_other:   118,619 ( 5.6%)
   monomorphic_iseq:    84,891 ( 4.0%)
  monomorphic_ifunc:    45,907 ( 2.2%)

Seems like a monomorphic case for a specific ISEQ actually isn't a bad way of going about this, at least to start...