GC object finalization not guaranteed

[Unknown W. Brackets]

Personally, I usually use destructors to clean up or to decrement use 
counts, bleach secure data, etc. but it should be guaranteed that if 
data is no longer allocated, the destructor is called.  That may be 
elsewhere in the spec, though.

Also, hardware failure should always be expected:

Webservers like Apache handle it.
Browsers like Firefox handle it.
Databases like MySQL handle it.
Operating systems like Windows handle it.
Productivity apps like Word handle it.
FTP clients like SmartFTP handle it.
Communication apps like Trillian handle it.

No one should esteem to write crapware.

-[Unknown]


Leandro Lucarella wrote:
> Unknown W. Brackets, el 18 de abril a las 16:51 me escribiste:
>> Well, I guess it would be doable to guarantee destruction, but *only* if
>> order of destruction was not guaranteed.
> 
> Yes, of course, order *can't* be guaranteed (unless you add read/write
> barriers and a lot of overhead at least =)
> 
>> In other words, at the end, the GC would not scan, it would just
>> destroy.
> 
> Yes, that's the proposal.
> 
>> Scanning is a problem, due to cycles and various other things,
> 
> I don't see any problems with scanning, it's just time-consuming and
> provides no benefits. Even more, the actual implementation do
> a fullcollect() (which marks, scans and sweeps).
> 
>> but destroying all roots would be potentially doable.
> 
> My proposal is to destroy everything live. There is no need to follow the
> roots, all memory known as live should be finalized. Again, there is no
> need on scanning the roots.
> 
>> I disagree that a log file needs guaranteed finalization, however.  It's
>> when you think that way that you ignore the possibility of hardware
>> failure.  I'm a server guy - and all the daemons I use log immediately
>> to the filesystem, without buffering.  Anything else would be
>> unacceptable.
> 
> Maybe you don't need that kind of security, but you would like your
> program to behave as expected in normal situations (i.e. when no hardware
> failure is involved).
> 
> Anyway the problem is no because of some example (I think it was a big
> mistake from my part to take the discussion into the examples field). The
> problem is the specs says now that "The garbage collector is not
> guaranteed to run the destructor for all unreferenced objects.", it
> doesn't say this is only applicable for destruction at the end of the
> program. As far as the specs go, a GC that don't call finalizers during
> collection *ever* is conforming.
> 
>