On Jun 25, 2009, at 11:41 AM, Peter Duniho wrote:
Well, as far as I'm concerned that's a bug then, and a somewhat
silly one at that. There should be no reason they couldn't easily
address that scenario, simply by using the thread attempting to do
the allocation to run the collection code (with the usual
synchronization/execution management that you'd need in any
collection/compaction scenario).
Heh-- yes, problems always seems silly and trivial when you haven't
studied them thoroughly. :)
I made the assumption that this should be an easy bug to address and,
not much research later, realized it is both very tough and not really
that important.
The first problem is that by the time allocation failures start
happening, the app and/or system is already so far into the weeds that
recovery isn't really going to be possible. For almost all
applications, an allocation failure is only caused by other bugs in
the app and no amount of exhaustive collection is going help.
Secondly, this problem goes away in the move to 64 bit. More or less,
anyway, as the collector has a limit to the total size of the GC zone.
Given the emphasis on 64 bit in Snow Leopard and that all Macs run 64
bit applications and have done so for quite a long time (the Mac Mini
being the last to be updated), there were better uses of the limited
engineering resource available.
As well, any solution that responds to rampant memory consumption by
spinning up the CPU(s) is held as suspect by default. It doesn't
benefit the user experience to have an application start sucking down
even more system resources in response to having already sucked down
too many system resources to start with!
The one allocation failure that is terribly relevant is when
allocation/free events outrun the collector. That is, when there is
so much temporary stuff being created and destroyed that the collector
can't keep up. This is a known issue in Leopard and has been largely
addressed in Snow Leopard, but it is still possible to trigger said
failure mode.
However, it is equally as often the case that such a failure mode is
better addressed by refactoring the application to recycle objects
instead of dealloc/alloc'ing them.
But then, that just reinforces the point that the Obj-C/Cocoa
garbage collection implementation has some refinement left to
accomplish. I'm glad to hear there've been bugs submitted on the
issue; I expect Apple will address them eventually. Until they do,
people who say that GC-managed memory in Cocoa isn't quite fully
baked yet will actually have a good point. ;)
Not really.
As noted above, allocation failures are generally a symptom and not a
problem in and of themselves. An application failing due to
allocation failures is most likely suffering from one or more of a
handful of things, none of which are specific to GC:
- leaks (Yes, you can write leaky GC code)
- poor design
- a user patient enough to throw a quantity of data at the app that
the developer never thought possible
b.bum
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
