Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make failed indy call sites still use specific-arity dispatch #4499

Closed
headius opened this issue Feb 21, 2017 · 1 comment
Closed

Make failed indy call sites still use specific-arity dispatch #4499

headius opened this issue Feb 21, 2017 · 1 comment

Comments

@headius
Copy link
Member

headius commented Feb 21, 2017

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.

@headius
Copy link
Member Author

headius commented Feb 21, 2017

This will be fixed along with #4482 via #4498.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant