Re: GC pros and cons
Re: GC pros and cons
- Subject: Re: GC pros and cons
- From: Marcel Weiher <email@hidden>
- Date: Thu, 25 Jun 2009 11:49:11 -0700
On Jun 25, 2009, at 0:54 , Peter Duniho wrote:
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.
This is true for those other systems. It is not true for Apple's GC.
It does not use bump-pointer allocation, and because it is not a
copying collector, it actually does have to explicitly deallocate
memory. Maybe this will change in the future, but I wouldn't exactly
hold my breath, because introducing a copying collector into a
language with unrestricted pointers (and pointer arithmetic!) is not
exactly trivial.
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.
That's not entirely true: scanning GC systems have a tendency to, as
the name implies, scan all memory that's in use, potentially causing
paging that an RC system will not have. Of course, they also try to
optimize this, and copying collectors can often do a good job of
keeping young-space in the caches. Alas, we don't have a copying
collector.
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.
The problem with that is that those lessons do not apply to the Apple
GC! Fast generation-scavenging copying collectors achieve very
different performance characteristics, they can allocate objects
order(s) of magnitude faster and incur no cost for deallocating young
objects. All that does not apply.
Cheers,
Marcel
_______________________________________________
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