auto classes and finalizers

Sean Kelly sean at f4.ca
Wed Apr 5 21:42:06 PDT 2006


kris wrote:
> Jarrett Billingsley wrote:
> 
> Interesting. It does appear to do that now, whereas in the past it 
> didn't. I remember a post from someone complaining that it took 5 
> minutes for his program to exit because the GC was run to completion on 
> all 10,000,000,000 objects he had (or something like that). The "fix" 
> for that appeared to be "just don't cleanup on exit", which then 
> sidestepped all dtors. It seems something changed along the way, since 
> dtors do indeed get invoked at program termination for a simple test 
> program (not if an exception is thrown, though). My bad.
> 
> Does this happen consistently, then? I mean, are dtors invoked on all 
> remaining Objects during exit? At all times? Is that even a good idea?

Yes, yes, yes, maybe :-)  It's the call to gc.fullCollectNoStack in 
gc_term.  There are alternatives that might work nearly as well (ie. the 
techniques you've used in the past) if shutdown time is an issue.

> That doesn't mean it should know about your design but, there again, it 
> shouldn't abort it either. That implies any additional GC references 
> held by a dtor Object really should be valid whenever that dtor is 
> invoked. The fact that they're not relegates dtors to having 
> insignificant value ~ which somehow doesn't seem right. Frankly, I don't 
> clearly understand why they're in D at all ~ too little consistency.

Because not having them tends to inspire people to invent their own, 
like the dispose() convention in Java.  Having language support is 
preferable, even if the functionality isn't terrific.

>> Yeah, I was thinking about that, maybe instead of just looping through 
>> all class instances linearly and deleting everything, just keep 
>> running GC passes until the regular GC pass has no effect, and brute 
>> force the rest. In this way, my method of "not deleting other objects 
>> in dtors" would delete the instance of the LinkedList on the first 
>> pass, and then all the Nodes on the second, since they are now orphaned. 
> 
> Yep
> 
> If references were still valid for dtors, and dtors were invoked in a 
> deterministic manner, perhaps all we'd need is something similar to 
> "scope(exit)", but referring to a global scope instead? Should the 
> memory manager take care of the latter?

In most cases this would work, but what about orphaned cycles?  The GC 
would ultimately just have to pick a place to start.  Also, I think 
disentangling a complex web of references could be somewhat time 
intensive, and collection runs are already too slow :-)


Sean



More information about the Digitalmars-d mailing list