• Russ Lewis <spamhole-2001-07-16 deming-os.org> Nov 11 2001
• a <a b.c> Nov 11 2001
• "Sean L. Palmer" <spalmer iname.com> Nov 12 2001
• "Walter" <walter digitalmars.com> Nov 12 2001
• Russ Lewis <spamhole-2001-07-16 deming-os.org> Nov 13 2001

Walter has noted that operator delete may be used to force immediate
garbage collection, particularly for situations where you either must
run the destructor now or when the object is a massive amount of memory
you want to release.

I would think that the garbage collector should check at this time and
not allow deletion if other references exist.  Thus, delete should throw
"ReferencesRemainException" if there are any remaining references (other
than the one used to call delete).  This would ensure garbage-collection
correctness while also allowing the programmer a powerful cleanup tool.

Thoughts?

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Russ Lewis wrote:
 
 Walter has noted that operator delete may be used to force immediate
 garbage collection, particularly for situations where you either must
 run the destructor now or when the object is a massive amount of memory
 you want to release.
 
 I would think that the garbage collector should check at this time and
 not allow deletion if other references exist.  Thus, delete should throw
 "ReferencesRemainException" if there are any remaining references (other
 than the one used to call delete).  This would ensure garbage-collection
 correctness while also allowing the programmer a powerful cleanup tool.
 
 Thoughts?


	Not all garbage collection algorithms keep reference counts.  The only
way some GCs could tell would be do a sweep of all the pointers and see
what remains.  I would imagine that most of the cases where you would
want to do a forced delete, you would not want the overhead of a full
garbage collection.   If the GC could determine this w/o a sweep, why
not have a reference count or shared property so you could avoid the
overhead of an exception?

Dan

I believe most garbage collectors also aren't foolproof... if it wasn't
using reference counts, you don't want it throwing an exception just because
there's some bit of data somewhere that looks an awful lot like a pointer to
the thing you're deleting.

Sean

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BEF5596.15595EAA deming-os.org...
 Walter has noted that operator delete may be used to force immediate
 garbage collection, particularly for situations where you either must
 run the destructor now or when the object is a massive amount of memory
 you want to release.

 I would think that the garbage collector should check at this time and
 not allow deletion if other references exist.  Thus, delete should throw
 "ReferencesRemainException" if there are any remaining references (other
 than the one used to call delete).  This would ensure garbage-collection
 correctness while also allowing the programmer a powerful cleanup tool.

 Thoughts?

It is a great idea, but it has implementation problems. The trouble is:

1) it is expensive to scan for references - almost as expensive as doing a
full garbage collection run.
2) sometimes references are ambiguous, and it would be an error to raise an
exception based on that

A better way is to use what I call a "memory stomper". The delete operation
will "stomp" on the object's data (filling it with FF's), so that any
dangling references to it will surely fail.

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BEF5596.15595EAA deming-os.org...
 Walter has noted that operator delete may be used to force immediate
 garbage collection, particularly for situations where you either must
 run the destructor now or when the object is a massive amount of memory
 you want to release.

 I would think that the garbage collector should check at this time and
 not allow deletion if other references exist.  Thus, delete should throw
 "ReferencesRemainException" if there are any remaining references (other
 than the one used to call delete).  This would ensure garbage-collection
 correctness while also allowing the programmer a powerful cleanup tool.

 Thoughts?

 --
 The Villagers are Online! http://villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]

Walter wrote:

 It is a great idea, but it has implementation problems. The trouble is:

 1) it is expensive to scan for references - almost as expensive as doing a
 full garbage collection run.
 2) sometimes references are ambiguous, and it would be an error to raise an
 exception based on that


I have been seriously pondering GC ever since I read the D spec, and think I
have a good idea how you could write a good GC using reference counting that
would also account for loops...but I have to ask my company if I can tell you
about it first.  Ofc, if I told you guys, you all would probably find all the
holes why it wouldn't work...but that's another story.

Working in IT sucks sometimes. :(

 A better way is to use what I call a "memory stomper". The delete operation
 will "stomp" on the object's data (filling it with FF's), so that any
 dangling references to it will surely fail.


This is good, sort of.  It does force the program to crash if you have a bug.
However, it crashes the program at a later date, at some location other than
the bug.  This sort of crash is VERY hard to debug.  I would still push, if at
all possible, for the crash to happen at the point of error.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]