search

chc4 / lineiform

A meta-JIT library for Rust interpreters
156 stars 4 forks source link

Deallocate JIT code on FastFn drop #5

Open chc4 opened 2 years ago

chc4 commented 2 years ago

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.

ohAitch commented 2 years ago

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 commented 2 years ago

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.