[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: About memory allocation failures....
From:       Kuba Ober <kuba () mareimbrium ! org>
Date:       2002-02-04 18:03:19
[Download RAW message or body]

> > If a compiler doesn't return an error/exception upon failed allocation of
> > an object
> > due to short-on-storage... BAAAAAAAAAAD compiler, and I'd suggest finding
> > another.  As far as not coding for exceptions... BAAAAAAD coding!!  It
> > should only be slower (if you can notice it) when an exception occurs,
> > which hopefully won't be often!
>
> There is actually a performance penalty when you enter a try { .. } catch
> block. It's small, though.
>
> However, catching bad_alloc solves the wrong problem. malloc()/new use
> sbrk and/or mmap. Consequently they only fail if the process can't
> allocate *address space*. This is only likely to happen if you hit a
> resource limit on virtual size, the 2/3/4GB per process limit or your page
> tables are full. This might happen and you might wish to handle this...but
> this isn't the case you have in mind.
>
> Running out of memory doesn't happen during malloc/new. It happens when
> the OS tries to allocate a physical page to back virtual memory that has

At last. Finally. Alex, you're great. This should be written in red big 
letters somewhere. People are so clueless about it.

I have actually hit the page table full situation a few times on embedded 
systems - there was only one process running (and the system load around 0.3 
- it was a lazy process, and the only one ;-), and the physical memory was 
almost full, and the kernel's OOM killer was off (by brute-force ;-). This 
was lean C code, so for most of the time the stack usage would oscillate by a 
few hundred bytes when the app was looping, and no network activity nor other 
processes were running. Trying to allocate a few tens of megabytes (with: no 
more swap available, i.e. swapfile full, and nearly no network/filesystem 
buffers / caches to get rid of!) then actually causes kernel not to have any 
space to extend page tables into, and that's the only situation when an 
allocation can fail. It was back in 2.2 days, and the VM code was slightly 
modifed by myself anyway.

> already been given to you via malloc/new. This happens when you first
> access the memory that malloc/new has returned. The OS responds by sending
> you a SIGSEGV. Your program never gets to see an allocation failure. In
> fact, my experience with Linux has been that the user gets bored of the
> swapping and resets the computer /long/ before swap space is exhausted.

So people, please remove all redundant, unnecessary, your-time-wasting, 
wordy, over-the-edge memory allocation tests - or, at least, don't code them 
anymore. Hmmmh, actually - that might be a good idea for me just to grep kde 
sources for new / malloc failure tests and remove them all?

Cheers, Kuba
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]