Memory issue with byte arrays on LispBM VESC implementation

[lrnd]

Hi,

I've recently been playing around with your LispBM implementation on the VESC which has been amazing! Such a great way of adding customization.

Recently I've been exploring the event-can-eid function to handle CAN messages through a lisp package and I've come across an issue of which I'm unsure if it is a bug or a problem on my end. Using your example in the documentation, with some minor tweaks :

(defun proc-eid (id data) (free data) )

(defun event-handler () (loopwhile t (recv ((event-can-eid . ((? id) . (? data))) (proc-eid id data)) (_ nil) ; Ignore other events )))

; Spawn the event handler thread and pass the ID it returns to C (event-register-handler (spawn event-handler))

; Enable the CAN event for standard ID (SID) frames (event-enable 'event-can-eid)

As you can see I added the (free ...) function so basically this will receive a CAN event and immediately free the array. However if you run this with a high volume of can messages you will see the memory usage grow quite high until some point when it seems the garbage collector frees up the memory. This will just repeat. I would have expected the memory to be freed before the next message is handled so the memory should stay constant.

Have I misunderstood something or is there an issue with the (free) function?

Thanks

[vedderb]

Which version of the firmware are you on? There have been some changes to the event system in the latest betas.

There will be some operations that use memory that cannot be affected with free, such as allocating the events. You don't have to worry about that as GC will take care of freeing up memory when needed. Generally it is not necessary to run free, it can just be useful when allocating large arrays often to prevent GC from running excessively and using up cpu time. GC is quite fast (takes around 1 ms to run on the VESC firmware), so there is not much to gain by running free manually for most programs.

When it comes to memory problems, if the program stops with some memory error is when you need to worry.

[svenssonjoel]

Free seems to work as intended in my tests. The event data is transferred as a flat_value from C to LBM and while doing so the runtime system allocates a copy of the data in LBM-memory. It should be possible to free arrays allocated in LBM-memory. Note though that it does not free ALL memory associated with the array, there will be a bit of heap-footprint that is only deleted once GC runs. Free should be used very carefully and only in situations when you are dealing with large arrays. One should not worry that memory is filling up, just as @vedderb says, GC will take care of it.

[lrnd]

Okay,

I appreciate the replies. I'm currently on the last release, version 6. Potentially it's the allocation of events causing the memory growth I see. I have seem some memory issues but I am pretty sure that's caused by my calling the free function. I will remove free from my program and let the GC handle it.

Thanks again.