site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Sep 4, 2008, at 5:15 PM, darwin-dev-request@lists.apple.com wrote: Or perhaps someone has a better memory management system in mind? = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... I'm developing an app that must handle thousands of image thumbnails. Obviously I need some method of handling all these thumbnails in memory. I'm building this app for Tiger so I can't use any spiffy Leopard features. It is my understanding that 32-bit apps cannot address more than 4 GB of virtual memory. Right now our app simply keeps these thumbnails in a backing store file, and as thumbnails are displayed, their respective chunk is mmap'd into memory from the backing store file. (We're mmap'ing instead of simply reading from the file to decrease loading times, so the thumbnail data is read lazily on a need basis). Here lies our problem: if too many photos are imported, there won't be enough virtual memory to handle all the thumbnail data, and the app will crash. Actually, your problem is that you think that by using mmap, you will get better performance than if you read the thumbnails explicitly. It's understandable why you might think this, but it's not correct. In your case, you have a better idea than the VM does about what thumbnails you are (and aren't) going to need in the immediate future, and you know better than the VM what data in the file translates to those bitmaps. So I need a way to cap how much of the thumbnail backing store file is kept in memory. Not really; what you need to do is implement your own thumbnail pager. There is no way for you to hint the VM such that it will do a better job than you can do by paging thumbnails yourself. mmap() is a convenient way of avoiding doing work in some general cases. Your workload isn't one of them, I'm sorry. This email sent to site_archiver@lists.apple.com