You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While fixing #4482, I discovered that indy paths not directly bound (e.g. initial or re-bind, failed sites, Java invocations, ...) always used varargs boxing and call path. This would negatively affect the performance of invokedynamic dispatches that never move on to direct binding.
The bind and rebind cases are not much of a concern; they immediately either directly bind or fail the site altogether. However, the failed cases, which includes sites with too many targets (think to_s), too many rebinds (e.g. against a new singleton class or many subclasses), Java invocations (Ruby to Java calls are not yet directly bound as in 1.7), and any other cases for which we can't determine a direct path would forever be boxing and unboxing arguments.
Note that methods which only have a varargs call path continue to always box, but we have not built logic to arity-split varargs into multiple possible specific-arity paths. Only actual fixed-arity methods get this treatment currently.
The text was updated successfully, but these errors were encountered:
While fixing #4482, I discovered that indy paths not directly bound (e.g. initial or re-bind, failed sites, Java invocations, ...) always used varargs boxing and call path. This would negatively affect the performance of invokedynamic dispatches that never move on to direct binding.
The bind and rebind cases are not much of a concern; they immediately either directly bind or fail the site altogether. However, the failed cases, which includes sites with too many targets (think
to_s
), too many rebinds (e.g. against a new singleton class or many subclasses), Java invocations (Ruby to Java calls are not yet directly bound as in 1.7), and any other cases for which we can't determine a direct path would forever be boxing and unboxing arguments.Note that methods which only have a varargs call path continue to always box, but we have not built logic to arity-split varargs into multiple possible specific-arity paths. Only actual fixed-arity methods get this treatment currently.
The text was updated successfully, but these errors were encountered: