C struct garbage collection not run frequently enough

[Sukera]

@mattsignorelli

There is an option to use standard malloc, calloc, free etc, so I could drop in the jl_malloc in there. Then I would just have to include libjulia and link against it, right?

Julia itself already loads libjulia, so that should just work if you’re calling the library from julia.

@mattsignorelli

Every operation/function takes in pointers to RTPSA in the C library, so doesn’t it make sense to just have the Julia side handle moving the pointers around properly?

What I’m saying is that the pointer is the object itself; Julia just abstracts that detail away. Mutable structs in Julia have pointer identity. In that way, Julia already handles the pointer correctly for you and you don’t have to emulate that manually.

@mattsignorelli

If I instead use only the RTPSA struct, then at each RTPSA construction I’d have to do an unsafe_load and each operation a pointer_to_objref for each.

You don’t have to do that manually though - the ccall interface handles all of that for you. See here. You’d implement Base.unsafe_convert for RTPSA to give pointer_from_objref and then you can just pass the object as-is back to C.

@mattsignorelli

And even still, Julia doesn’t know how long the coef array is in RTPSA, which is the most memory intensive array in the struct here.

Julia doesn’t need to know that though - your struct would be exactly the same, pointer fields and all. If you want to inspect the array you can implement some accessing sugar to handle the unsafe_load for you (or use unsafe_wrap with own=false for printing), but other than that, you don’t need to change anything about your struct.

The advantage of this approach lies mainly in the fact that there are no allocations at all anymore. The memory was already allocated by C, there’s no wrapper and since every struct is freed in the same way, the function passed to finalizer can also just be a regular function instead of an anonymous function.