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

[vm/ffi] Support freeing Pointer.fromFunction trampolines #50610

Closed
dcharkes opened this issue Dec 2, 2022 · 4 comments
Closed

[vm/ffi] Support freeing Pointer.fromFunction trampolines #50610

dcharkes opened this issue Dec 2, 2022 · 4 comments
Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. library-ffi

Comments

@dcharkes
Copy link
Contributor

dcharkes commented Dec 2, 2022

Currently, we never free these trampolines. The argument being that we hand out a pointer to C and we don't know when C is done.

However, in C use cases where the user knows when they are done with it, they currently have no way to free the trampoline.

In Java (with Runnable) and ObjectiveC (with Block), we do know when we're done with a callback. Consequently, package:jnigen and package:ffigen could generate the calls to free the trampolines.

@dcharkes dcharkes added area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. library-ffi labels Dec 2, 2022
@liamappelbe
Copy link
Contributor

In Java (with Runnable) and ObjectiveC (with Block), we do know when we're done with a callback.

The way the ObjC bindings are written at the moment, there are no per-Block function pointers. There's a couple of trampolines that are used by all the blocks. So this wouldn't really apply.

There are 2 ways of constructing Blocks: from an ordinary Dart function, or from a native function pointer (which would usually be from Pointer.fromFunction). In the latter case, I suppose we could add a flag to the constructor that tells the Block that the function pointer was created by Pointer.fromFunction, and that the Block now owns the function pointer and should free it when it's destroyed.

@mkustermann
Copy link
Member

Right now the Pointer.fromFunction() return values are functions that carry no state. As long as that's true, there's no reason to have a free mechanism.

Only if we start associating state with Pointer.fromFunction() (e.g. by having it an isolate/isolate-group state, or closure state) this becomes relevant.

What we will need is a mechanism for higher-level language bindings's to free dart-related state associated with their callbacks (e.g. ObjC blocks, Java objects that may refer to dart objects/closures).
=> This is tracked already, see dart-lang/native#225, dart-lang/native#204

@liamappelbe
Copy link
Contributor

NativeCallables can be manually closed by the user, so this bug is essentially fixed even though you still can't close Pointer.fromFunction callbacks.

@dcharkes
Copy link
Contributor Author

We should actually tell users to migrate. I've filed:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. library-ffi
Projects
None yet
Development

No branches or pull requests

3 participants