Re: Garbage collector vs variable lifetime
Re: Garbage collector vs variable lifetime
- Subject: Re: Garbage collector vs variable lifetime
- From: Peter Duniho <email@hidden>
- Date: Sun, 8 Jun 2008 22:55:36 -0700
Date: Mon, 9 Jun 2008 01:03:16 -0400
From: John Engelhart <email@hidden>
On Jun 7, 2008, at 10:10 PM, Michael Ash wrote:
If you don't like undefined behavior, then C-based languages are a
poor choice. If you don't like nondeterministic object lifetimes,
then
garbage collection is a poor choice.
If your statement regarding nondeterministic object lifetimes is true,
and (as I think it has been shown) deterministic object lifetimes is
sometimes required for deterministic program behavior, does this not
imply that the current GC system is fundamentally flawed?
Not at all. A GC system doesn't have non-deterministic object
lifetimes. It has non-deterministic object deaths.
The lifetime of an object under GC is well-defined, at least with
respect to code correctness. As long as code is actually using a GC-
managed object, the lifetime of the object is assured. It is only
when the object becomes unreachable that its lifetime _may_ be ended,
and the very moment that the object becomes unreachable, no code had
better depend on that object staying alive.
The lifetime may be extended arbitrarily by the GC system, but this
is immaterial to correct code. And in fact, a non-GC system could do
the same thing.
For example, imagine a non-GC memory manager that had a separate
thread responsible for returning objects that have been freed/deleted
to the free-list...that data would theoretically be usable until the
thread gets around to putting it back in the free-list, and in fact
probably even until the memory was then reallocated by something
else. But surely you would not consider code correct if it continued
to reference and use memory that had been passed to free/delete. Right?
In either case, once the code has discarded its last reference to the
memory (either by the reference simply no longer existing, as in a GC
system, or by calling a memory management function like free or
delete, as in some other systems), the memory management system is
free to deal with that block of memory as it likes. Code that relies
on the the data in memory sticking around even after it no longer is
referencing the memory is what's flawed, not the memory manager.
The non-determinism that exists in a GC system (and this is not at
all unique to Obj-C's system) is absolutely not "fundamentally
flawed". It won't affect correct code at all.
Pete
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden