A listener does get added to every display object. If you have a lot of display objects, that will be a lot of memory allocated to closures.
Well, these are a lot of allocations - outside the initial program startup, once in an idle state, I wasn't expecting to see much change there (certainly not every frame). I'd thought that calling clearSamples would suffice to clear the previous state. Still, that would explain the relatively large size of the allocations.
You might want to breakpoint in the FocusManager when idle and see what if being added to the displaylist. Lots of folks get burned in funny ways by playing a Flash animation somewhere in their app (as a busy indicator or just some visual effect).
But a closure is big. It isn’t a 32-bit/64-bit reference like it is in C++. I think I was told it is upwards of 100 bytes. There is some non-optimized bookkeeping going on that they may get around to cleaning up someday, but really, I haven’t seen an app truly dying from the size of closures. It is usually a sign of some deeper problem.
Thanks - I'm approximately doing that by just adding an Event.ADDED listener to the stage and stepping over the shape objects that are getting added each frame. I'm just not seeing delete events for the ones that show up in my sampling. At this point I'm assuming that a large proportion of these allocations correspond with persistent things that are legitimately not getting deleted.
I'm not so much concerned about the size of the closures per se, so much as trying to reduce the total number of allocations per frame (both as a best practice and in order to make it easier to track down memory leaks).
Have you figured out how to match any delete samples? Also note that the delete samples won’t come until GC actually runs and if the system is too busy, it may not be getting around to it. GC can have low priority when the display list is active. You can try forcing GC and see if the delete samples show up.
But if lots of adds are happening when “idle”, that’s something to be looked at.