site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com In a situation where the malloc request: is < MALLOC_ABSOLUTE_MAX_SIZE but > [total RAM + total free swap partition space] or > ulimit -v , or ulimit -d (regardless of soft/hard) Cheers, -- Terry _______________________________________________ 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... On Dec 25, 2008, at 4:58 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote: it seems that malloc() returns a non-NULL pointer (i.e. without error). It returns a pointer into a page mapping in the process virtual address space. No physical pages are allocated until you touch them. This can exceed total RAM plus swap +because of memory overcommit, which has pretty much been SOP on unix since the DEC VAX version introduced virtual memory. Terry, Why does linux treat this situation as a malloc error? Does UNIX conformance imply acceptance of situations like this that have been addressed by the linux community? Jack (NB: I can talk about what administrative limits mean in the context of UNIX conformance, if you want, but that doesn't seem to be the issue you want to talk about here) Assuming, for the sake of your argument, things work the way you have indicated on all Linux distributions with every malloc() implementation, I wouldn't so much say Linux has "addressed" the "situation" as that they've made different design decisions than us based on implementation details and how they expect their product to be used. I've previously pointed out one difference in implementation detail that bears strongly on this particular issue, which is static allocation of swap partition space on Linux systems. Given a static bounding on that, if they ignore competing processes, they can make decisions based on how much swap will be available in the future, no matter what else happens; we can't, since creating/extending (non- swap) files detracts from the actual amount for us. On the other hand, on Linux, if you run out of swap because you have two processes that unwittingly cooperate to run you out, game over. If the same thing happens on Mac OS X (or Windows), and there's free disk space available, more space is allocated automatically, and you merrily chug along. Unless you have badly broken application code or an already full disk, that's going to be a much better user experience than "time to repartition your disk and reinstall your OS". If you think one of Linux's decisions is wrong, you can give the maintainers of whatever distribution code that implements things a different way, and Alan Cox or one of the other gatekeepers can make a decision to accept or reject your code. If you have the same problem with Mac OS X, you can do the same thing via a problem report (or even file the report without including code; you don't have to be a computer programmer to report what you think is a problem). At this point, I suggest you file a problem report; please include your use case that demonstrates why it's a problem, since that will give the engineer it lands on more ammunition to make the change you want if they can say it's a demonstrable customer-facing issue. This email sent to site_archiver@lists.apple.com