As discussed with @jonasfj and @mkustermann, maybe it would be better to provide a Pointer to a C function as finalizer, as the GC does currently not support running Dart code for finalization.

class Pointer {
  attachFinalizer(Pointer<NativeFunction<void Function(Pointer)>> finalizerPointer) {

  }
}

You might also want to include a sizeHint so we can signal an approximate size of the object to the GC.
Even if I don't know the exact size of the object I'm holding on to, I know if it's approximately 12 bytes, 12kb, or 12mb give or take a few orders of magnitude.

We should implement this in the initial release since so many users seem to need it.

I think we should estimate 3 weeks for this, given that we need:

• Support for attaching finalizers to Pointer (based on existing finalizer support).
• Maintaining a reference to the original from derived pointers.
• Maintaining a reference to the original from external typed data.

We should implement this in the initial release since so many users seem to need it.

Yeah, we really need it.

Looking at https://dart-review.googlesource.com/c/sdk/+/123662, I don't think this solves all issues, especially with long lived structures or strings in a static method.

For example, libpng's png_create_read_struct needs the version string of libpng from link-time to ensure that ABI-incompatible changes haven't occurred (https://github.com/glennrp/libpng/blob/libpng16/png.h#L922). Yes, you could also wrap the function with another C library to forward the version correctly, but then you have to make sure that Dart, the auxiliary native library, and libpng are all in sync and are ABI compatible.

I'm just hoping that that CL isn't the final design for pointer finalizers.

When will this feature be available?

@vaind I think the best you can do right now is the following:

@pragma('vm:never-inline')
Object reachabilityFence(Object obj) {
  return obj;
}

and use this as a replacement for dart_keepalive. That should keep the obj alive (though it will break if we start removing parameters which are never used from functions in AOT compiler, but we don't have any immediate plans to work on something like that AFAIK).

Many thanks @mraleph, you saved my day!

Update 2020-06-26:
.....

Expose finalizers in Dart.

/// Return a pointer object that has a finalizer attached to it. When this
/// pointer object is collected by GC the given finalizer is invoked.
///
/// Note: the pointer object passed to the finalizer is not the same as 
/// the pointer object that is returned from [finalizable] - it points
/// to the same memory region but has different identity. 
Pointer<T> finalizable<T>(Pointer<T> p, void finalizer(Pointer<T> ptr)) {

}

What does it mean @dcharkes ? Where can we find finalizable?

There's lots of things about this Finalizer API that I don't understand. If you could help me clarify some of these, I'll be grateful...

1. According to my understanding, a Finalizer is a function we can attach to a Dart handle (in C) that will be called when the object is garbage collected. Is this right?
2. To create a Finalizer, I have to pass the Dart object itself to native code as a Handle (which is Dart_Handle in C), which will then register a function that Dart can call to "finalize" whatever memory the native code is allocated. However, the Dart_NewPersistentHandle function returns a Dart_PersistentHandle. What am I supposed to do with it, pass it back to the Dart class that called the function registration routine? If that's the case, does that mean that I would not need the initial object (or pointer) that points to native memory and will instead use whatever is returned by the Dart_NewPersistentHandle in Dart?

I'm sorry if these questions sound dumb, it's just that I'm not familiar with the whole Finalizer thing, and I'm trying to make sure that I don't leak memory when I'm working with native code cause I'm creating lots of them

I don't like this design and I'm confused: do I need to change the .c code in order to call it from dart? what if the .c lib is a 3rd party library which I don't have source code ?

Do I need to change the .c code in order to call it from dart? what if the .c lib is a 3rd party library which I don't have source code ?

You can write a C library that wraps the original library which attaches the finalizers. And yes, that is not ideal. Multiple packages are facing this issue.

That's why we're investigating adding finalizers in Dart-land. (This issue, #35770, is tracking adding FFI-specific Dart finalizers. However, https://github.com/dart-lang/sdk/issues/45455 proposes to add finalizers to Dart in general.)

Until one of those two issues has been resolved, your options are:

• Finalizers in C.
• Do memory management in another way. For example with (1) lexical scoping through arena from package:ffi, (2) manual memory management by adding free calls in your code, or (3) providing a release method in your API that users have to call when done. (Of course there are scenarios in which none of these three work, for example when your objects get passed to a framework that does not tell you when it's done using your object.)

1. According to my understanding, a Finalizer is a function we can attach to a Dart handle (in C) that will be called when the object is garbage collected. Is this right?

Yes.

2. To create a Finalizer, I have to pass the Dart object itself to native code as a Handle (which is Dart_Handle in C), which will then register a function that Dart can call to "finalize" whatever memory the native code is allocated. However, the Dart_NewPersistentHandle function returns a Dart_PersistentHandle.

I presume you meant Dart_NewWeakPersistentHandle function returns a Dart_WeakPersistentHandle.

Or Dart_NewFinalizableHandle which returns a Dart_FinalizableHandle.

What am I supposed to do with it, pass it back to the Dart class that called the function registration routine?

Dart_FinalizableHandle and Dart_PersistentHandle are used to remove the finalizer if you would want to remove it.

If you don't ever want to cancel it, you can ignore the return value of Dart_NewFinalizableHandle, because it gets automatically deleted when the object is garbage collected.

You should not disregard a Dart_WeakPersistentHandle that would leak memory. So I suggest you use Dart_FinalizableHandles instead.

If that's the case, does that mean that I would not need the initial object (or pointer) that points to native memory and will instead use whatever is returned by the Dart_NewPersistentHandle in Dart?

I presume you meant Dart_NewWeakPersistentHandle or Dart_NewFinalizablePersistentHandle here.

You can pass the Dart_NewWeakPersistentHandle or Dart_NewFinalizablePersistentHandle back to the Dart class and store it there as a Pointer. If you'd ever want to cancel the finalizer, you would use that Handle the cancel the finalizer.

I'm sorry if these questions sound dumb, it's just that I'm not familiar with the whole Finalizer thing, and I'm trying to make sure that I don't leak memory when I'm working with native code cause I'm creating lots of them

No problemo!

P.S. These kind of questions are not really issues with Dart. So StackOverflow might be a better place for them than making this GitHub thread very long!

Update 2020-06-26:
.....
Expose finalizers in Dart.

/// Return a pointer object that has a finalizer attached to it. When this
/// pointer object is collected by GC the given finalizer is invoked.
///
/// Note: the pointer object passed to the finalizer is not the same as 
/// the pointer object that is returned from [finalizable] - it points
/// to the same memory region but has different identity. 
Pointer<T> finalizable<T>(Pointer<T> p, void finalizer(Pointer<T> ptr)) {

}

What does it mean @dcharkes ? Where can we find finalizable?

This does not exist. This was a proposed API. That will likely never exist because of the pursuit of adding Dart non-FFI-specific finalizers: #45455.

Given that C finalizers are available, and Dart finalizers are tracked in #45455, I'm going to lock this issue for now.

If you have questions about how to use the finalizers in C, please post your questions on StackOverflow.

If you want to chime in on the Dart finalizer design discussion, please post in #45455.

If for whatever reason #45455 does not come to be, I'll unlock this discussion again.

@dcharkes - are we ready to close this issue now?

Yes!

Available in https://api.dart.dev/stable/2.18.3/dart-ffi/NativeFinalizer-class.html.