On 12/1/05 12:21 AM, Scott Fraser didst favor us with:
> 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 an issue in Mac OS X.
>
> 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.
Has to be, otherwise all code that uses pointers would fail miserably, and
everything uses pointers.
> 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".
Assumptions are evil. Handles are never relocated in Mac OS X unless they
need to grow beyond their original size. Memory allocated to handles is not
released when a handle is resized down.
> 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.
VM takes care of memory management so that memory fragmentation isn't an
issue like it used to be. As far as your code is concerned it can allocate
whatever size block you need as long as there's enough remaining of your
4Gig virtual memory space to fill the request. However, long before you run
out of memory VM is going to start swapping pages to disk and performance
will suffer.
Larry
_______________________________________________
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
