Expose pointer to free from allocators

[mraleph]

This enables to write code like this:

final buf = malloc.allocate<Uint8>(len).asTypedList(len, finalizer: malloc.nativeFree);

[dcharkes]

Closes: dart-lang/native#910

[dcharkes]

@mraleph How about the interplay of Arena and the two allocators you've added the functionality to?

Are we expecting devs to mix and match allocators?

  using((arena) {
    final str = "myString".toNativeUtf8(allocator: arena);
    final buf = malloc<Uint8>(len).asTypedList(len, finalizer: malloc.nativeFree);
  });

In general we have a question about combining finalizers and eager finalization (dart-lang/sdk#49906), but in this specific case, the native finalizer can't be cancelled, so there's no reason to use the arena for the list backing the typed data.
It feels weird, using two allocators, but, I think it's the right thing to do.

[dcharkes]

lgtm with comments.

[dcharkes]

Add interface keyword.

We could consider making it just a marker interface and not implementing Allocator and making the allocators types in their own right (then the name would be NativeFreeable). But having it implement the allocator makes it useful for specifying the type of malloc and calloc. So that's probably better.

[mraleph]

Are we expecting devs to mix and match allocators?

I think this change specifically addresses non-arena based usage, if you have malloc allocated memory and want to make sure you automatically free it (e.g. when you pass data you get through FFI to a consumer which works with typed data).

[dcharkes]

cc @lrhn for a potentially better name for NativeFreeableAllocator.

lgtm from my side.

[lrhn]

All in all, this feels a little to much like a hack, more than a coherent design.
You need a function, so you make the existing class, which happens to know about the function, expose it, in its public API.

I have many ideas for how to completely redesign Allocator, but a more conservative design would be to expose Malloc and Calloc classes (final and with private constructors), and have them expose the native free function as a static getter.

Then you have

final class Malloc implements Allocator {
  Pointer(T) alloc<T>(int count) { ... }
  void free(Pointer allocation) { ... }
  static final Pointer<NativeFunction<Void Function(Pointer)>> nativeFree = ...;
  static final Pointer<NativeFunction<Pointer Function(IntPointer)>> nativeAlloc = ...;
}
// ....
const Malloc malloc = MallocAllocator();

and similarly for CallocAllocator where nativeAlloc takes two arguments.

That gives you a link between the Allocator instance and its functions, without exposing them from the object itself.

Or if you prefer, drop the NativeFreeableAllocator type, and expose CallocAllocator and MallocAllocator types that each have instance getters for nativeFree and nativeAlloc, but not shared supertype.

Then you can't abstract over the NativeFreeableAllocator and get to its nativeFree, but it's an abstraction that doen't work for alloc, and which feels glued on the Allocator API. I'd see if it could work before introducing a shared supertype just for nativeFree.

[dcharkes]

I have many ideas for how to completely redesign Allocator, but a more conservative design would be to expose Malloc and Calloc classes (final and with private constructors), and have them expose the native free function as a static getter.

Hm, I had the same thought in the comments (but with a marker interface in case someone would want to write generic code).

Then you can't abstract over the NativeFreeableAllocator and get to its nativeFree, but it's an abstraction that doen't work for alloc, and which feels glued on the Allocator API.

The use cases that we have don't require a shared super type.

final buf = malloc.allocate<Uint8>(len).asTypedList(len, finalizer: malloc.nativeFree);

Making a Malloc and Calloc type would work for these use cases.

[mraleph]

I have many ideas for how to completely redesign Allocator, but a more conservative design would be to expose Malloc and Calloc classes (final and with private constructors), and have them expose the native free function as a static getter.

I am not sure I like this proposal - it makes the code look strange: allocate and free are also effectively static, but they are still instance methods because Dart does not allow to abstract over static methods. So you end up with the code like this:

final x = malloc.allocate<Uint8>(len).asTypedList(len, finalizer: Malloc.nativeFree);

Notice there is malloc and Malloc in the same line which looks somewhat weird to me.

Or if you prefer, drop the NativeFreeableAllocator type, and expose CallocAllocator and MallocAllocator types that each have instance getters for nativeFree and nativeAlloc, but not shared supertype.

I can do this - I don't think any other major changes are worth it.

[dcharkes]

Please also add a test in test/allocation_test.dart.

[dcharkes]

Thanks @mraleph !