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

Deallocate JIT code on FastFn drop #5

Open
chc4 opened this issue Sep 12, 2021 · 2 comments
Open

Deallocate JIT code on FastFn drop #5

chc4 opened this issue Sep 12, 2021 · 2 comments
Labels
good first issue Good for newcomers

Comments

@chc4
Copy link
Owner

chc4 commented Sep 12, 2021

What is says on the tin: ususally JITs can't ever deallocate JIT bodies without explicit safepoints, since another thread could be currently executing the code and would segfault.
Since we JIT closures, and are using Rust where everything has explicit lifetimes, we can actually always deallocate the JIT code when the Fn goes out of scope, since by definition it is unreachable from any code. Also we don't have any multi-threading support yet lol.

Get rid of the mem::forget(f) in JIT compilation and store the original function in the FastFn instead, too, so that we properly run destructors of the members of the closed environment.

@chc4 chc4 added the good first issue Good for newcomers label Sep 12, 2021
@ohAitch
Copy link

ohAitch commented Feb 17, 2022

Also we don't have any multi-threading support yet lol.

I imagine the FastFn is as Send and Sync as the input closure?

@chc4
Copy link
Owner Author

chc4 commented Feb 17, 2022

I meant more that the fact that FastFn doesn't implement Send+Sync means that there are no cases in which a closure is being dropped while we are compiling other closures or running it. I think we'd have to worry about that in the event of e.g. #12 being implemented; it'd have to make sure to use reference-counted closures in order to make sure that everything stays alive while it is doing work on another thread, for example. That would have to add Send+Sync(?) bounds to

pub fn speedup<F>(&mut self, f: F) -> impl Fn(A)->O where F: Fn(A)->O {
or something in order to make sure the closure is safe to access from whatever async worker thread, but not this work, and I'm not sure if it makes sense to make FastFn itself Send+Sync if we don't need to either.

Basically I was just being cheeky and the fact that we aren't caring about multithreading at all currently makes this easy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants