www.digitalmars.com         C & C++   DMDScript  

D - delete throws ReferencesRemainException?

reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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))) ]
Nov 11 2001
next sibling parent a <a b.c> writes:
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
Nov 11 2001
prev sibling next sibling parent "Sean L. Palmer" <spalmer iname.com> writes:
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?

Nov 12 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
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))) ]

Nov 12 2001
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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))) ]
Nov 13 2001