lineiform icon indicating copy to clipboard operation
lineiform copied to clipboard

Deallocate JIT code on FastFn drop

Open chc4 opened this issue 2 years ago • 2 comments

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 avatar Sep 12 '21 21:09 chc4

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

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

ohAitch avatar Feb 17 '22 00:02 ohAitch

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 https://github.com/chc4/lineiform/blob/4a104c994561282318179ec50a3a6b00b3f6e8c4/lineiform/src/lib.rs#L103 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.

chc4 avatar Feb 17 '22 03:02 chc4