• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: memory. and a lot of continual small object allocations and deallocations.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

References: 
 >memory. and a lot of continual small object allocations and deallocations. (From: Ben Dougall <email@hidden>)

  • Prev by Date: Re: Show / Hide Window
  • Next by Date: Re: Does release Really Release?
  • Previous by thread: Re: memory. and a lot of continual small object allocations and deallocations.
  • Next by thread: Re: Make the action of a NSMenuItem, which has a subMenu, to work
  • Index(es):
    • Date
    • Thread