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

References to "include"d functor applications from other units causing closure allocations (Slack discussion 2020-06-30.) #198

Open
mshinwell opened this issue Jul 1, 2020 · 2 comments

Comments

@mshinwell
Copy link

No description provided.

@mshinwell
Copy link
Author

mshinwell 3:32 PM
I'm looking at another interesting allocation test failure (down to the last two I think)
3:33
There is a functor from another library applied in the current unit and the result is included (edited)
3:33
Then a function calls one of the functions from that functor
3:33
Closure has a projection directly from the symbol of the other unit at the application site
3:34
We end up with the function having a free variable for the callee. The free variable is bound, prior to the lambda, as part of the include mechanism to the field projection.
3:34
Presumably if cross-library inlining were enabled everything would be ok, but when it's off, this causes a closure allocation

@chambart
Copy link

chambart commented Jul 1, 2020

I have a simple idea that I'd like to try on that. I'll see if it works well.

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

No branches or pull requests

2 participants