Re: memory. and a lot of continual small object allocations and deallocations.
Re: memory. and a lot of continual small object allocations and deallocations.
- Subject: Re: memory. and a lot of continual small object allocations and deallocations.
- From: Timothy Ritchey <email@hidden>
- Date: Fri, 18 Apr 2003 10:15:53 -0500
It depends on what you mean by "back to the system."
The default zone allocation routines use the scalable_malloc
implementation defined in the Darwin's standard C library project Libc
(under gen.subproj). The scalable_malloc functions use three different
allocation fulfillment and management implementations depending on the
size of the allocation requests. Allocation requests are broken down
into either small, those requesting less than 12,228 bytes, or three
pages of memory; large, those requests between three and 24 pages of
memory (98,304 bytes); and huge, those requesting over 24 pages of
memory.
For small allocations, the scalable zone keeps a list of regions, and a
linked list of free blocks within those regions. When a request is made
for a block of memory, first the free list is checked to see if there
is any available space, and only if there is no room in the existing
regions is a new region added. As blocks are allocated and freed, the
regions act as a pool of resources which can be quickly accessed by
malloc without needing to call the underlying page allocation
functions. For larger allocations, the zone keeps a hash table of
memory blocks. The zone does not immediately destroy blocks when an
process frees them. If a request for memory comes along, this
free-but-not-deleted list is first checked for a large enough block to
fulfill the request before requesting pages from the operating system.
Finally, the zone keeps a separate list of huge memory blocks in a
simple dynamic array, and doesn't try to performa any pooling of
resources with these blocks. For small and large memory allocations,
when you call free on a pointer to a memory location, that block of
memory doesn't necessarily immediately cease to exist. Instead, the
scalable zone implementation tries to keep a pool of resources at hand
that can quickly fulfill requests for memory.
Cheers,
tim
On Friday, April 18, 2003, at 08:07 AM, Ben Dougall wrote:
does cocoa's runtime deal with continual allocation and deallocation
of small amounts of memory from small objects reasonably? does it not
release memory immediately back to the system, incase the app needs
some new memory for something else the next second/minute? is there
anyway for your app to reserve a chunk/block of memory, so when it
allocates and deallocates it doesn't release the memory back to the
system but keeps it for later?
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.