auto garbage collection race condition?
auto garbage collection race condition?
- Subject: auto garbage collection race condition?
- From: Michael Link <email@hidden>
- Date: Wed, 14 Jan 2009 13:37:50 -0600
I'm running into a scenario where it appears the application is
allocating memory faster than it can be reclaimed by garbage
collection. I believe this is how it happens.
There are a pool of threads that are used to collect some data as it
is collected (by using NSXML* objects, XQuery). In the beginning the
generational collections seem to keep up well since almost all of the
NSXML* objects become garbage very quickly. After a small bit of time
though no garbage collection takes place and memory is consumed to the
point of exhaustion. (I have AUTO_LOG_COLLECTIONS=YES set to see when
collections take place).
Some analysis during the period that no collections are taking place
actually reveals that the collector thread is at this point:
#0 0x001d3a37 in Auto::Bitmap::bit at AutoBitmap.h:131
#1 0x001dca84 in Auto::Region::is_pending at AutoRegion.h:209
#2 0x001db587 in Auto::Admin::is_pending at AutoAdmin.cpp:415
#3 0x001ee3cd in Auto::Subzone::is_pending at AutoSubzone.h:472
#4 0x001eec1e in Auto::scan_pending_blocks_visitor::visit at
AutoMemoryScanner.cpp:631
#5 0x001eed55 in
Auto::visitAllocatedBlocks<Auto::scan_pending_blocks_visitor> at
AutoBlockIterator.h:53
#6 0x001eddb4 in Auto::MemoryScanner::scan_pending_blocks at
AutoMemoryScanner.cpp:658
#7 0x001ede0e in Auto::MemoryScanner::scan_pending_until_done at
AutoMemoryScanner.cpp:680
#8 0x001edfb5 in Auto::MemoryScanner::scan at AutoMemoryScanner.cpp:731
#9 0x001e8c31 in Auto::Collector::collect at AutoCollector.cpp:64
#10 0x001e0f89 in Auto::Zone::collect at AutoZone.cpp:1324
#11 0x001d20c7 in auto_collect_internal at auto_zone.cpp:258
#12 0x001d282c in auto_collect_with_mode at auto_zone.cpp:375
#13 0x001d28c2 in auto_collection_thread at auto_zone.cpp:397
#14 0x91dc3095 in _pthread_start
#15 0x91dc2f52 in thread_start
Whenever I break into gdb to see where it's at during this point
Auto::visitAllocatedBlocks<Auto::scan_pending_blocks_visitor> has
always been in the stack trace. My guess would be that "pending"
blocks are being added faster than they are scanned...
To get around this problem I've tried making each thread call
objc_collect(OBJC_EXHAUSTIVE_COLLECTION|OBJC_WAIT_UNTIL_DONE);
after it's done with its task, but it doesn't actually seem to wait at
all. Since there already seems to be a collection taking place the
call returns and the thread continues.
Is there anyway to truly block execution until collection has
finished? Are there any callbacks that could notify when collection
has started and ended?
I wouldn't mind moving the temporary objects allocation to an
unscanned zone, but there doesn't seem to be an equivalent
CoreFoundation way to use XQuery as there is in NSXMLNode.
--
Michael
_______________________________________________
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