On Sun, 30 Jan 2005 07:35:35 -0500, Skip Haughay <email@hidden> wrote:
> One possible strategy that I am working on is this. I pick a buffer
> size, some guestimate as to what the application is going to need to
> keep running. I haven't come up with a real value for this yet, but in
> my tests, I am just grabbing a 64 MByte chunk.
>
> Just prior to doing any operation that could allocate a huge amount of
> memory and fail, I first attempt to grab a 64 MByte chunk of RAM, as a
> contingency buffer. Allocate it, do nothing with it, except hold onto
> it. I then proceed with my regular memory allocations. IF the
> allocations fail, they roll back. IF they succeed, great. In either
> case, I then let go of the contingency block, and cross my fingers that
> there is enough memory available for the application to keep running
> nicely and not choke somewhere in which I have no control. So
> essentially all big consumers of memory in my application would be
> framed by a grab at a contingency buffer, and a release of it
> afterwards. IF you can't get the buffer, you can't proceed with the
> requested operation.
>
> Anyone see any problems with such a strategy? And does anyone have any
> suggestions as to a good strategy for figuring out the size of this
> "set-aside" memory?
The only problem here is that until you actually access any of that "
set-aside" memory it's just virtual and in no way effects the availability
of any real (physical) memory. You're no closer or further from thrashing
your swap file.
OTOH you have inserted a buffer between your application running out of
virtual addresses. It definitely helps with that problem.
--
Enjoy,
George Warner,
Schizophrenic Optimization Scientist
Apple Developer Technical Support (DTS)
_______________________________________________
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
