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))) ]