Re: GC pros and cons
Re: GC pros and cons
- Subject: Re: GC pros and cons
- From: Peter Duniho <email@hidden>
- Date: Thu, 25 Jun 2009 00:54:09 -0700
On Jun 24, 2009, at 9:15 PM, Jeff Laing wrote:
1. If your objects use (scarce) resources that are not themselves
subject to GC (file handles, network connections, whatever), you'd be
[snip]
2. If you expect objects to be returned to the free memory pool "the
instant that those objects aren't required" then GC isn't going to
satisfy you.
[snip]
However, in this case, it's the expectation that's unreasonable, not
GC behavior. You don't actually care that unreferenced objects die
instantly. You actually care than new objects can be created quickly.
Actually, I just care that they can be created at all.
Then Quincy's comments are ten times more true for your situation. :)
In a GC system, the fact that an object hasn't been collected yet
doesn't interfere with future allocations. All it means is that the
GC hasn't gotten around to collecting the object yet. If and when a
new object is required, and if the GC hasn't yet gotten around to
collecting dead (unreachable) objects, and if there is not enough
space to fulfill the new object, at that point in time the GC _will_
start working on collecting dead objects.
You're not going to see a memory allocation failure simply because of
non-determinism in the garbage collector.
Furthermore, it is more typical that there _is_ space already
available on the heap to satisfy an allocation request, and in a
typical GC system allocations are much faster than for the alloc/free
paradigm. I admit, I don't know the specifics of the Obj-C system,
but in other systems an allocation is simply a matter of updating a
_single_ pointer and of course there are no explicit deallocations at
all. An alloc/free generally involves a heap with a free list, where
every allocation involves splitting a block, updating the free list
and possibly other guard structures, and deallocations involve similar
work but going the other direction.
GC systems, in my experience, tend to have more "jitter", due to the
intermittent operation of the collector. But they have the potential
to be more efficient overall, depending on the implementation.
My situation is that "free memory is a scarce resource" for the
class of applications that I'm working with, and there's no way that
an IDisposable() can be bolted on to solve "memory" problems without
completely replicating Release().
Even in .NET, IDisposable (which is an interface, not a method...the
method is "Dispose()"), it's not a solution for memory scarcity
issues, nor is there anything in the referenced article that suggests
it is. There's nothing one can do in a Dispose() method or finalizer
to improve GC performance with respect to _memory_ allocations. Those
are there to help deal with unmanaged objects, including memory
allocated via unmanaged techniques.
Obj-C 2.0/Cocoa has similar issues, and they are in fact addressed in
similar ways. The main difference I note is that because GC is a new
thing for Obj-C, whereas it was there from the outset for languages
like Lisp, Java, C#, etc. you have a _lot_ more situations where the
boundary between "managed" (i.e. garbage-collected) and
"unmanaged" (i.e. retain/release, never mind all the usual non-memory
resources) is an issue, and there's less in the way of "collective
wisdom" in terms of using the GC system.
Over time, I expect that to be much less of an issue.
Its not reasonable to say "but virtual memory will solve that
problem" because it just won't.
Nobody's said that. A GC system really has practically the same
relationship with the virtual memory manager as the retain/release
system.
My customers have terabytes of data any of which might be called
into memory and cached there for performance reasons because we
can't know when they are going to randomly access any of them, and
the data is more complex than just a single row from a database table.
We aren't using "hanging around in memory" as our caching mechanism,
we hold things in LRU chains and we uncache the oldest ones first.
A GC solution that doesn't immediately free the object when we
release it means that we need to manually poke the GC machine to get
the benefit of the uncache, whereas if we *know* that it will
deallocate objects when we tell it to, we're fine.
What "benefit of the uncache" are you referring to? A delayed
collection of the object isn't going to interfere with future
allocations. Is there some other "benefit" you're thinking of?
As has been pointed out, this isn't a .NET list, and I don't care
strongly about this topic, except in as much as I was expressing an
opinion about "the things that certain people with certain mindsets
worry about and why GC upsets them".
You're right, it's not a .NET list. But, Java and .NET programmers
have been working in an environment very similar to that found in
Cocoa, except that they've been exposed to garbage collection a lot
longer than Cocoa-only programmers have been. While this mailing list
is for Cocoa topics, it's useful to take advantage of lessons learned
in other frameworks when applicable, and it's definitely applicable
here.
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