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

List:       kde-devel
Subject:    RE: About memory allocation failures....
From:       "Schmidt, John" <John_Schmidt () compuware ! com>
Date:       2002-01-30 14:51:14
[Download RAW message or body]

On Tuesday, January 29, 2002 7:12 Rodolfo Conde Martinez wrote:
> On Tuesday 29 January 2002 16:23, Alex Hayward wrote:
> > 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.
> >

>	Yes youre right, so i think i'll be removing the NULL returning
checks from 
> my apps, well all that they taught me at school about always checking for 
> malloc/new was pointless afther all.....or well not that bad as i supose
its 
> good programming practice but of course with a little performance 
> penality....

I think you need to reread Alex's comments, the performance penalty he
mentions
is when you do try {...} catch {...} block, not simply doing an if check for
NULL
on a malloc().  If you do NOT check for NULL and subsequently try to write
to the
storage addressed from your NULL pointer, this is what you get:

[aecotdv0] $./myprocpp
.
.
allocated memory at 200a04d8

getargs returned arguments = ./myprocpp
getprocs returned pi_adspace = 536932750  pi_size = 201
getprocs returned pi_drss = 201  pi_trss = 5  pi_dvm = 201  pi_prm = 0
pi_tsize = 4065
getprocs returned pi_dsize = 722128  pi_sdsize = 0

allocated memory at 200c04e8

getargs returned arguments = ./myprocpp
getprocs returned pi_adspace = 536932750  pi_size = 233
getprocs returned pi_drss = 233  pi_trss = 5  pi_dvm = 233  pi_prm = 0
pi_tsize = 4065
getprocs returned pi_dsize = 853216  pi_sdsize = 0

allocated memory at 0
Segmentation fault(coredump)
[aecotdv0] $

For this example I set my ulimit datasize artificially low at 1M.

As far as Alex's reply to my statements, I WAS indeed thinking of this
scenario because
you will hit the ulimit way before his 2nd scenario occurs, if that CAN
occur.  I say 
this because you can't possibly be referencing every virtual page (and
backing phys page)
in your address space at any given moment.  The VMM =should= page out one of
your 
unreferenced pages to supply the backing phys page for the newly malloc'd
storage.  If that
doesn't occur, the UNIX & Linux VMMs are pretty rudimentary.  

Further discussion should go offline, email me direct.

John Schmidt
ServerVantage Development
Compuware Corporation
john.schmidt@compuware.com
http://www.compuware.com/products/vantage


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