-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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] Remove memory management from API #38520
Comments
If we change this, we would probably do it before the next release or we risk breaking all our users. |
Yeah, good idea. Would you like to make a design for this that we could discuss?
Definitely. Even though we're really explicit on that this is an experimental feature and that the API might/will change, I agree that it's important to prioritize things that change the API. |
Instead of removing it immediately, we can also mark it as |
My design is just that we remove |
Does this have impact on user code besides changing |
Not as far as I know. |
This would make the following 3 issues obsolete:
|
We should ensure we can find the right |
It turns out that using We must either remove |
We just need https://github.com/dart-lang/tflite_native/pull/29/files to land before we can remove them entirely. |
The PR for |
This is blocked on non-generic structs in the SDK, since we need to roll the latest package:ffi and package:tflite_native to fully remove the deprecated methods. |
We can remove all deprecated methods together, tracked in issue #38860. I'll create a CL that removes all of them. (Unless you already have a CL to remove the memory management ones @sjindel-google?) |
Presently, the
Pointer
class contains wrappers formalloc
andfree
.However, we should consider a more neutral position on memory management. It doesn't makes sense to expose these as primitives in WebAssembly, and we can already implement them in Dart.
We can:
Pointer.allocate
andPointer.free
and move them topackage:ffi
.Allocator
API, e.g.:However, the
Allocator
API should arguably live inpackage:ffi
anyway. That would facilitate using dependency injection to mock or replace the allocator and implement different allocation strategies.The text was updated successfully, but these errors were encountered: