We recently added the ability to optimize a known cfunc with custom code generation for it.
Previously we performed this lookup with a switch statement on the address of the c function being called. This commit swaps that out for a hash lookup on the method definition. For now I've kept this limited this to cfuncs, but it wouldn't take significant changes to make this work for other method types.
This implemenation is similar to how the interpreter keeps track of which BOPs (basic operations) are redefined
This has a few advantages:
Doesn't the C function's symbol to be exported (they're often static)
This could support VM_METHOD_TYPE_OPTIMIZED in the future.
This could support VM_METHOD_TYPE_ISEQ in the future. Kernel#class would be a good candidate for this since to yjit it will just be a constant push as we already know the class through BBV.
Slightly cleaner to declare
Less tightly coupled to each method's implementation
And a couple minor trade-offs:
The looser coupling could be seen as a disadvantage (I don't think so,
If a cfunc is defined multiple times we would need to declare it on each definition. ex. BasicObject#== and BasicObject#equal?. This is rare compared to using an alias.
Use an st_table for optimized method codegen
We recently added the ability to optimize a known cfunc with custom code
generation for it.
Previously we performed this lookup with a switch statement on the
address of the c function being called. This commit swaps that out for a
hash lookup on the method definition. For now I've kept this limited
this to cfuncs, but it wouldn't take significant changes to make this
work for other method types.
This implemenation is similar to how the interpreter keeps track of
which BOPs (basic operations) are redefined
This has a few advantages:
would be a good candidate for this since to yjit it will just be a
constant push as we already know the class through BBV.
And a couple minor trade-offs:
each definition. ex. BasicObject#== and BasicObject#equal?. This is
rare compared to using an alias.