But it's rarely a good idea to piggyback. Most resources are much more limited or time sensitive than memory. So you should free them immediately.

Even when your resource -is- memory it sometimes is a very very very bad idea to free via garbage collection.

Reference counting almost gives you as soon as, but it has trouble handling circular references. That is fixable, but not, AFAIK, in a way that’s both reasonably performance, frees resources as soon as they become unreachable, and isn’t too restricting.

The fix you refer to is one, but it falls under ‘not reasonably performant’.

One could also make it illegal to have cycles (easy way to do that: make it illegal to update any references). For many, many, that will fall under ‘too restricting’, though.

Alternatively, allow updates to references, but give every allocated object a ‘bit’ that indicates whether, from it, a reference can be reached that contains such an updated reference that points to an object created later (maintaining that property is doable, but may not be ‘reasonably performant’)

You can use that later: when the reference count of an object goes to zero, and the object has a reference to an object O with that bit set, check whether the graph reachable from O can be reached from elsewhere. Again, that’s doable, but likely not performant.

It somewhat depends on how common circular references are in real world code, though. I’m not aware of any papers researching that.

Destructors do not free the memory of the object being destroyed, but they can free memory that its fields point to.