datzach / destructors Goto Github PK

Sample code uses dtor_track instead of dtor; anonymous function variable somehow causes the weak reference to stay alive ("Destructed!" is never printed).

Because of how this detects GCed objects via weak references, it looks like there are a couple of possible ways that it could keep objects alive longer or even leak them:

Each step when dtor.update() runs, each object gets one chance to run its destructor(s). If an object holds a reference to another object, and its destructor also needs to use that object, then the GC can only collect the first object that frame- it's only possible to GC the second object after the destructor runs and its reference to the second object disappears.

For example: if you have a chain of N objects, each one and its destructor referencing the next, which the GC could ordinarily free all together, it will take N calls to dtor.update() for the whole thing to get cleaned up.

Or: if you have a cycle of these objects, the array of tracked DtorInstances will hold onto all of them, and the GC will never get a chance to start the process- all the weak refs will stay alive forever.

I haven't written enough GML from this era to know how common these patterns might be. It might be possible to improve the first case by repeating the loop in dtor.update() until it finds no more destructors to run, but OTOH that might re-introduce the problem the GC tries to solve by processing generations incrementally. I'm not sure whether it's possible to fix the second case with the existing API, either. So overall take this with a grain of salt!