I’ve just put up a new experimental build (3123) that I’m hoping will solve a problem in the audio engine when tearing down certain MIDI connections. I’m a little concerned this change might cause some objects not to get released.
To monitor this I’ve exposed two new metrics in the monitor panel - “Objects” and “Locked Zombies”:
Mostly you can ignore these numbers, but if you happen to notice the Locked Zombie count stay at anything other than zero - and especially if you can reproduce it, please let me know.
For the technically savvy and/or curious:
The “objects” count is the number of instantiated C++ audio engine objects. Mostly the lifetime of these objects tracks with their managed .NET counterpart and they usually get cleaned up when the garbage collector runs.
ie: the object count won’t necessarily drop immediately after unloading a large song although by this point the objects are disposed and not hanging onto any resources - they’re lightweight.
Once the GC collects an object it enters a “zombie” state. Non-locked Zombies are cleaned up almost immediately. Locked Zombies are zombies that have outstanding strong locks on them and hang around until those explicit locks are released.
Strong locks are mostly used to manage the execution plan object graph and to ensure cross group references remain valid until objects are fully removed from the graph. As of this build however they’re also used to manage some edge case MIDI connections where the lifetime of a MIDI source it’s parent execution node aren’t necessarily the same.
My concern here is strongly locked circular references - it should never happen, but hard to prove.
