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

List:       kde-devel
Subject:    RE: About memory allocation failures....
From:       Alex Hayward <xelah () xelah ! com>
Date:       2002-01-29 16:23:02
[Download RAW message or body]

On Tue, 29 Jan 2002, Schmidt, John wrote:

> Rodolfo Conde Martinez
> > 	mmmhh.....havent check all the kde code....but isnt it free of
> exception
> > checking (as it does code bigger and slower doesnt it ?? )....and i guess
> not
> > all compilers have the -fno-check-new and -fno-exceptions like g++, so if
> > there isnt exception checking what happens ? the program just crashes ???
> > wouldnt be a good idea to set a function handler in the kdelibs maybe or a
>
> > handler apropiated for each app ??
>
> 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
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.

The only way out of this is to turn overcommit off in your OS. Not many
OSs can do this (neither Linux or FreeBSD is one). It's also not usually a
very useful thing to do most of the time.

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