`Bytes#Resize` memory leak on HashLink

[NotHyper-474]

On HashLink, Bytes is directly used as a structure for an instance of haxe.io.Bytes, unlike in HXCPP where these are instantiated from a passed value parameter, the problem is that only in the latter this allows the allocated buffer to be disposed when no longer in use. From my understanding, it was presumed that simply assigning the address to b would allow it to be tracked by the GC, which according to this is incorrect.
This is not only theory; when profiling an application, I've observed unfreed memory coming from the function.

[tobil4sk]

Not sure I fully understand the claim, by Bytes which type do you mean exactly? Could you also send a link to the assignment you are talking about here?

it was presumed that simply assigning the address to b would allow it to be tracked by the GC

The GC comment you linked is talking about how if you use malloc to allocate some memory, you can use it as hl.Bytes. However, you cannot rely on the GC to free it for you and you still have to call free manually. As far as I understand there is no malloc at play with haxe.io.Bytes here?

Also note that haxe.io.Bytes is no longer shadowed in modern versions of lime.

If you resize, it is possible that the allocation size doesn't decrease, but this is probably intentional to save on allocation time and in case you resize again in the future. I'm not sure if this would be considered a leak though, since it still gets freed when you clear up the object.

[NotHyper-474]

I guess I wasn't clear enough. The Bytes I mean is the C++ type from the util folder. When I said it's used as a struct for haxe.io.Bytes I meant to say in the HL CFFI functions. A lot of them, if not all, have haxe.io.Bytes in their parameters and return types, then in ExternalInterface.cpp their implementation have those represented as Bytes*, which would be the same type I'm referencing here.

And the cases where a leak happens seem to always be ones that follow this pattern: on the Haxe side, a buffer is created using Bytes.alloc(0), then passed to a CFFI function which in turn will call Resize on the passed Bytes* pointer, this is done every time on a new instance since it's a local variable, so the mallocated buffer isn't able to be reused.

This doesn't occur in the HXCPP FFI though, since, albeit both use the same class, they are handled differently: HL just passes a pointer directly, CPP creates one from a value type argument, which apparently causes it to be tracked by the usingValue and hadValue maps so their memory can be freed, but I don't really understand the code to know if that's the case.