On 11/30/05 9:21 PM, "Scott Fraser" <email@hidden> wrote:
> The app I'm working on can use large amounts of memory. On a G4, it
> could likely eat up the entire 4Gig address space. Unfortunately,
> Apple's documentation seems a bit out of date. (Or maybe I'm not
> looking in the right places.)
>
> 1. In OS X, how likely is memory fragmentation?
Not likely at all for any program whose memory requirements are anywhere
near reasonable.
> 2. I presume that pointers to blocks of memory (via "NewPtr" or
> allocated with "malloc") are "non-relocatable" in that the block of
> memory is never moved. The page may get swapped out, but the address
> range is still "reserved" until it is freed.
The logical address of an allocated memory block remains constant but the
physical address of its backing store, if there is one, can of course
change. Note that allocating a block of memory simply reserves a range in
the process's 4GB logical address space - no RAM or disk space is assigned
as a backing store until those pages of memory are actually accessed. For
this reason algorithms that keep doubling the size of their memory
allocation requests (such as a std::vector) are more efficient than they may
at first appear.
> 3. I presume that in OS X, Handles (via "NewHandle") are still
> "relocatable", in that the memory block that is indirectly pointed to
> can be moved unless the handle is "locked".
No. A Handle will no longer move unless it is specifically resized. And even
in that case only the resized Handle will move, all other Handles will stay
where they are.
Since pointers and other blocks of memory can be resized, there is no
benefit from allocating a Handle. And in fact the extra layer of
indirection, plus the fact that a Handle (or a pointer) is not guaranteed to
be page-aligned makes malloc a much better choice for memory allocation.
> 4. I presume that "malloc" does its best to organize and reuse small
> or similar-sized blocks of data to avoid fragmentation. However, when
> large non-relocatable (ie pointer) blocks are requested (> 250K or some
> other limit) I presume it just grabs what it can. I presume that many
> large requests could cause problems, and might cause "fragmentation" to
> the extent that other large non-relocatable blocks may be difficult to
> allocate.
Each process has 4GB of logical address space all to itself. So unless the
program actually allocates and uses several gigabytes of RAM, fragmentation
is unlikely because each block of allocated memory can be assigned a logical
address far away from any other - and one that is likely to remain far away
since most apps never come near to requiring 4GB of memory storage.
Greg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
