< Back to IRCAM Forum

Memory Allocation?

OpenMusic
#1

Hello! Any simple tips on what I might change to avoid errors like these? They happen when I’m far enough into an OM session and I’ve already evaluated some of my patches that have “repeat-n” calls with either a high enough “n” or a sufficient number of evaluations. Even when I wait long enough for the process to terminate, there still seems to be something building up in memory. In the case of this screenshot, each evaluation is generating 5 measures of music and selecting 4 images randomly from a directory list of about 20,000 photos. If I set the “n” of the repeat-n at say 20, I can evaluate successfully a few times, but I’ll eventually get the allocation error, seemingly no matter how long I wait. I have to close the OM session to get back to normal. I can attach a patch if it helps. Thanks!

memory.jpg

#2

Hi – I have seen this problem before, but generally when OM explicitely allocates external memory (typically for audio management) and doesn’t deallocate it correctly.

As you probably know, memory management in Lisp (and OM) is done through automatic garbage collection, which make it easy to program (you don’t have to allocate/deallocate memory), but sometimes harder to control. Memory should be released as soon as the data is not reachable anymore (that is, when no other object refers to it) – you can trigger a garbage collection manually in LispWorks by calling (GC-ALL). Ensuring that your data will be collected and freed is not always straightforward, and several reason can stand on the way: circular dependencies, side effects, etc.

Would you mind sharing your patch so I can see if there’s anything specific in there ?
(If possible, the most simplified possible version of it that would allow me to reproduce the problem.)

Jean

#3

Thanks Jean. Great info. I’m seeing improvement already by rewriting some of my functions, replacing recursives with “dotimes” and am going to continue to do so, and will attach a patch when I have things more streamlined. Again, much appreciated!
best, Leonard

#4

Hi Leonard.

Checked ‘slots’-box vs. new instances?

I have no idea whether this relates to the troubles you’re seeing, but one mistake i’ve seen many people do is unneccesary duplicating of data inside sub-patches. E.g. to access some data from an outside chord-seq inside a sub-patch, a new chord-seq is added to the input box of the sub-patch. This is ok in simple situations, but when patches and systems grow more complex, this approach soon starts pushing memory usage.

Instead, inside the sub-patch, take care to use ‘slots’-versions of the structure passed to the input, and access whatever data from the outside you’re interested in. Check attached example.

-anders

Skjermdump-fra-2019-01-23-23-26-41.png

#5
unneccesary duplicating of data inside sub-patches

And of course, this is even more important inside loops or recursive programs…

#6

Thanks, Anders! I’ve never dealt with the slot vs instance distinction in patches, and I’m looking forward to playing with it. Much appreciated!
Best,
Leonard