Skip to content

use invokedynamic instead of the reflection API when possible #85

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

Closed
wants to merge 2 commits into from
Closed

Conversation

forax
Copy link

@forax forax commented May 22, 2019

The compiler is patched to use invokedynamic instead of the reflection API when it doesn't know the function to call statically.

Invoking a static method or a constructor is done just by delaying the resolution at runtime.
For the other invocations, an inlining cache is installed to trap the receiver class and do the resolution each time there is a new receiver class.

For all invocations, if a resolution find several overloads, invokedynamic is wire up to call the reflection API, said differently, in case of multi-dispatch, this patch fallback to use the reflection.
Also If no method is found during the resolution, the Reflector API is called so the error messages (and the call stack) are exactly the same.

I've not touch to the error warning in case of reflection because the decision to make an invocation inlinable or not is done at runtime.

@pzygielo
Copy link
Contributor

@forax
Copy link
Author

forax commented May 23, 2019

Hi Piotrek,
i've seen that after having created the pull request, so i've started a discussion on the mailing list.
many thanks.

@forax forax closed this May 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants