[haiku-commits] Re: BRANCH midar-github.master - src/preferences/bluetooth src/servers/app src/kits/tracker src/add-ons/screen_savers/message headers/os/support

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Tue, 20 Nov 2012 14:03:48 +0100

On 11/20/2012 01:30 PM, Jonathan Schleifer wrote:
Am 20.11.2012 um 12:57 schrieb Ingo Weinhold:

There are enough machines out there with < 2 GB on which Haiku runs well 
enough. One shouldn't disable virtual memory, but some people do. And in emulation 
both is typical even.

Even then, new will still happily return a pointer, even though you have less 
RAM + Swap combined. As long as the MMU can create mappings (and that has 
nothing to do with the amount of memory on the system or the amount of swap!), 
new returns a pointer. new just uses malloc, that's why.

In Haiku we over-commit memory only for stack areas -- i.e., as you write, the area is created without actually reserving physical memory. For other areas, including heap areas, memory is committed upfront, though.

I don't understand this conclusion. Why would it crash when running out of 
virtual address space? If all allocations are checked, there's no reason why 
the program should misbehave.

If the MMU can't even map something anymore, it means the process already has 
to use gigabytes of memory - more than you could ever have using actual memory. 
This means something went berserk and allocates in a loop or something. The 
exception would then finally terminate it.

OK, I see. The conclusion is not that because of the exhaustion of address space something will crash, but that the something that led to the exhaustion of address space will also cause a crash. In case of the app server that isn't necessarily so. E.g. memory for bitmaps allocated by clients is also mapped in the app server address space. So in 32 bit mode it is relatively easy to exhaust without anything going wrong in the app server itself. Crashing the app server in such a case wouldn't be helpful.

A scenario where it actually can crash is when running out of physical memory, 
since we over-commit our stacks. Ideally we would deal with that situation 
gracefully as well, though that isn't entirely trivial.

That can't be caught anyway. new returns a pointer, even if no memory is 
available. On the first write, the memory is actually allocated.

Well, it is possible to catch the SIGSEGV. Properly handling it so that everything is brought back to a well-defined state and the thread can continue is rather involved, though. Obviously the whole situation can be prevented by committing physical memory for the app server threads' stack beforehand.

CU, Ingo


Other related posts: