Ben Hinkle wrote:
> "B.G." <gbatyan@gmx.net> wrote in message news:d62qm8$2krb$1@digitaldaemon.com...
> 
>>Jarrett Billingsley wrote:
>>
>>>"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d5p0gn$3k0$1@digitaldaemon.com...
>>>
>>>
>>>>Current the GC is run at program exit. Many of us wish it weren't. To me the three main reasons why it shouldn't run is
>>>>1) it is run after the module dtors which means your destructors can't rely on anything that depends on the module being "initialized"
>>>>2) it sucks up significant time to quit when the OS will reclaim "everything" anyway (people may disagree on what "everything" means)
>>>>3) dtors aren't guaranteed to run anyway so in particular people can't count on them to run at program exit.
>>
>>>Well, what I'm suggesting is that the spec *change* so that dtors _are_ guaranteed to be run.  I find that to be rather important behavior.
>>>
>>
>>OH! I wanted to ask this question since ages.
>>What does it actually mean that dtors are not guaranteed to be run?
> 
> 
> The second-to-last paragraph (and the last paragraph, really) in
> http://www.digitalmars.com/d/class.html#destructors
> says that the GC doesn't have to reclaim unreferenced objects. This is to allow conservative collectors that interpret ambiguous pointers (which are values that the GC scans that could be pointers to an object) as live references. Since this is very rare during normal use the destuctor will usually run. The debate above is about requiring destructors to run at some point before program exit.
> My own view is that the garbage collector's job is to manage memory resource and any other resource should be managed by hand or let the OS clean it up at exit. Letting the GC manage the resource is like getting a "don't call us - we'll call you" from a client. You never know if or when they are actually going to call. :-P
> 
> 
>>If excluding following conditions from consideration:
>>
>>- unplugging PC's power, etc :)
>>- segfault
>>- Ctrl-C
>>- reaching end of main() function
>>- calling exit
>>etc. etc.
>>
>>what happens when a program executes for hours, how do dtors behave during 'normal' operation? ARE they still not guaranteed to be called?
> 
> 
> It could happen - ambiguous pointers can occur any time.
> 
OK, I fully understand the problem of ambigous pointers, that's a different problem.
So there are for sure no other conditions why a destructor wouldn't be called, right?

Apropos ambigous pointers, I was always wondering... Do you know how inteligent is the GC about areas where it looks for pointers? for example, does it see the entire stack as an array of pointers or it is aware of stack ranges containing only pointers or ranges definitely not containing pointers? What about class members? Any Ideas?

>>>what happens when a program executes for hours, how do dtors behave during 'normal' operation? ARE they still not guaranteed to be called?
>>
>>
>> It could happen - ambiguous pointers can occur any time.
>>
> OK, I fully understand the problem of ambigous pointers, that's a
> different problem.
> So there are for sure no other conditions why a destructor wouldn't be
> called, right?

Well, technically the GC calls the destructor when it collects a given piece of memory and there are no guarantees that the GC will collect a piece of memory - for whatever reason. In practice the only reason I know of why the GC doesn't collect something is due to ambiguous pointers and program-exit behavior (it scans with the data segment as roots). But that doesn't mean some other GC won't come along that could arbitrarily decide to never collect something or other.

> Apropos ambigous pointers, I was always wondering... Do you know how inteligent is the GC about areas where it looks for pointers? for example, does it see the entire stack as an array of pointers or it is aware of stack ranges containing only pointers or ranges definitely not containing pointers? What about class members? Any Ideas?

The dmd GC doesn't know if a piece of memory contains pointers or not. The boehm collector has two memory pool - one for types that might contain pointers and one that doesn't. Eventually the dmd compiler could detect if an allocation could be made from a pointer-free pool (eg allocating a string) but for now the only API assumes every allocation can contain pointers. The stack doesn't have type info on it so the GC scanning code can't skip any ranges of it.