couldn't the garbage collector have something like

gc.force_collect()

not guaranteed to be real time...but it would go through and collect *everything * possible and run destructors on all.

In article <ca6mm5$1rbi$1@digitaldaemon.com>, J Anderson says...
>
>hellcatv@hotmail.com wrote:
>
>>why not run the destructors all dead objects at the end (in the atexit)? that should solve the problem, no?
>> 
>>
>Good idea but some programs never end.
>
>-- 
>-Anderson: http://badmama.com.au/~anderson/

hellcatv@hotmail.com wrote:

>couldn't the garbage collector have something like
>
>gc.force_collect()
>
>not guaranteed to be real time...but it would go through and collect *everything
>* possible and run destructors on all.
>  
>
There is a fullcollect().  Personally I would like some more options with the gc, like some collections that return after a guaranteed amount of time.

>In article <ca6mm5$1rbi$1@digitaldaemon.com>, J Anderson says...
>  
>
>>hellcatv@hotmail.com wrote:
>>
>>    
>>
>>>why not run the destructors all dead objects at the end (in the atexit)?
>>>that should solve the problem, no?
>>> 
>>>
>>>      
>>>
>>Good idea but some programs never end.
>>
>>-- 
>>-Anderson: http://badmama.com.au/~anderson/
>>    
>>
>
>
>  
>


-- 
-Anderson: http://badmama.com.au/~anderson/

In article <ca6g6p$1il6$1@digitaldaemon.com>, Walter says...
>
>What isn't guaranteed is the object being collected. If it *is* collected, the destructor will be run.

New questions then.

In what circumstances will the object be collected?
In what circumstances will the object not be collected?

Arcane Jill

hellcatv@hotmail.com wrote:

> why not run the destructors all dead objects at the end (in the atexit)? that should solve the problem, no?

in a convervative collector the GC might mistakely think an object is still alive even at exit. See the explanation in the link I posted before: http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html Once the GC decides an object is dead it runs the destructor. It's deciding what is dead that is hard.

> In article <ca6g6p$1il6$1@digitaldaemon.com>, Walter says...
>>
>>
>>"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca6ego$1fmt$1@digitaldaemon.com...
>>> In article <ca5s60$l06$1@digitaldaemon.com>, Walter says...
>>>
>>> >> Not (2). You yourself have told me in the past that when the garbage
>>> >collector
>>> >> collects the object, it may choose not to execute the destructor.
>>> >
>>> >I must have misspoke, because when the gc collects an object, it *does*
>>run
>>> >the destructor.
>>>
>>> How curious. In your post http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/2766, you said:
>>>
>>> >There's still another problem, though. D's GC does not *guarantee* that destructors will get run for non-auto objects. Therefore, you might want
>>to
>>> >keep a list of all the secure arrays created that haven't been wiped yet, then on program close with a module destructor, go through the list and wipe any remaining ones.
>>>
>>> Now, I believe you Walter. You wrote the compiler, and I believe you. But,
>>I
>>> think these two statements are in contradiction, and now I don't know
>>which one
>>> to believe.
>>
>>What isn't guaranteed is the object being collected. If it *is* collected, the destructor will be run.
>>
>>

Ben Hinkle wrote:

> hellcatv@hotmail.com wrote:
> 
>> why not run the destructors all dead objects at the end (in the atexit)? that should solve the problem, no?
> 
> in a convervative collector the GC might mistakely think an object is still alive even at exit. See the explanation in the link I posted before:
>
http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html
> Once the GC decides an object is dead it runs the destructor. It's deciding what is dead that is hard.

I think the idea behind the proposal was: at program exit, *every* object can be considered dead. If that final run of the gc is the very last thing the program does, you know for sure that none of the objects will ever be accessed any more.

Norbert Nemec wrote:

> Ben Hinkle wrote:
> 
>> hellcatv@hotmail.com wrote:
>> 
>>> why not run the destructors all dead objects at the end (in the atexit)? that should solve the problem, no?
>> 
>> in a convervative collector the GC might mistakely think an object is still alive even at exit. See the explanation in the link I posted before:
>>
>
http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html
>> Once the GC decides an object is dead it runs the destructor. It's deciding what is dead that is hard.
> 
> I think the idea behind the proposal was: at program exit, *every* object can be considered dead. If that final run of the gc is the very last thing the program does, you know for sure that none of the objects will ever be accessed any more.

The static data still needs to be scanned for roots even at exit:

Object please_dont_collect_me_first;
class A {
  ...
  ~this(){ please_dont_collect_me_first.print(); }
  ...
}

might seg-v if the static object is collected at exit before A is collected. So it has to be considered "alive" when A's destructor runs. So it has to always be considered "alive" even at exit.

Using module destructors might help here, but I haven't thought about it.

Walter wrote:

<snip>
> What isn't guaranteed is the object being collected. If it *is* collected,
> the destructor will be run.

On the D for Win32 page, WinMain includes:

    gc_term();		// run finalizers; terminate garbage collector

Does this mean:

(a) it's necessary to manually call this function on exit to make sure everything's destructed?
(b) there's a subtle difference between "finalizers" and "destructors"?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

<hellcatv@hotmail.com> wrote in message news:ca6kbl$1of7$1@digitaldaemon.com...
> why not run the destructors all dead objects at the end (in the atexit)? that should solve the problem, no?

Sometimes people don't want to do this for performance reasons. Also, it's rather pointless for cleaning up resources, since the OS will already clean up any resources held by an exiting program.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca6ro6$22tt$1@digitaldaemon.com...
> In article <ca6g6p$1il6$1@digitaldaemon.com>, Walter says...
> >
> >What isn't guaranteed is the object being collected. If it *is*
collected,
> >the destructor will be run.
>
> New questions then.
>
> In what circumstances will the object be collected?

When the gc runs a collection and it cannot find a reference to that object.

> In what circumstances will the object not be collected?

When there's a reference to it somewhere in the 'roots' scanned by the gc. The roots are things like the stack, registers and static data.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:ca7emf$30cm$1@digitaldaemon.com...
> Walter wrote:
>
> <snip>
> > What isn't guaranteed is the object being collected. If it *is*
collected,
> > the destructor will be run.
>
> On the D for Win32 page, WinMain includes:
>
>      gc_term(); // run finalizers; terminate garbage collector
>
> Does this mean:
>
> (a) it's necessary to manually call this function on exit to make sure
> everything's destructed?

Yes. But recall that this is rarely necessary, the OS will routinely clean up any dangling resources on the exit of a process.

> (b) there's a subtle difference between "finalizers" and "destructors"?

There is no difference in D.