Re: the different between aaa m1[100] and aaa *p = new [100]
evaned_at_gmail.com
Date: 03/14/05
- Next message: Mads Jensen: "Re: Does filename has to be the same as funtion name??"
- Previous message: eddy_ruslim_at_telkom.net: "Re: Adress of a struct vs address of its first field"
- In reply to: Richard Cavell: "Re: the different between aaa m1[100] and aaa *p = new [100]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 14 Mar 2005 10:57:08 -0800
As far as alignment is concerned, I have no clue. It's platform and
implementation defined, but I can't even give examples; I'm not that
knowledgable about how alignment works or anything like that. Perhaps
someone else can fill that in.
However, typically the heap size is much larger than the stack size. I
think the default stack size is usually about a meg give or take.
However, I've run programs that have used a couple hundred megs of heap
space without changing compiler settings. So your heap is almost
guranteed to be larger.
A couple more things of note: new/malloc takes a little time, because
it has to find an appropriate block of memory. Depending on the
implementation of malloc/delete, this could be anywhere from usually
constant time to linear with the number of unallocated blocks. I don't
know what the glibc version of malloc uses, nor any other common
implementation. I do have Lion's Commentary on Unix here, and looking
at the implementation of malloc in it (a really freaking old copy of
Unix from the PDP11 days), it looks like it uses the first fit
algorithm. This means that it looks through a list of free blocks
(areas of memory that aren't allocated) until it finds one that is at
least large enough to fit the requested size in. In any case, this time
is usually insignificant, but it's worse than "completely free", which
is essentially the case with automatic variables. (I'm ignoring
constructors and any other initialization here.)
Also, there is a bit of space overhead as well. Remember that you don't
pass free() the size of the allocated block, so it must keep that
information somewhere. Often (usually? almost always?) this is kept in
a header before the block. So if you get back p from malloc, there will
be a word at *(p-sizeof(int)) that holds the size of that block.
Also, another point of interest is that usually programs don't release
memory back to the OS until they exit. For instance, my understanding
of the working of glibc is that when malloc is called it goes to the OS
and requests memory from it, gets it, and sets up its own structure in
it of free blocks, and allocates memory. When that memory gets freed
from your code, glibc marks that block as unallocated but doesn't do
anything else. Even if that block was the only allocated space on that
page, it won't return it to the OS. The thinking is that system calls
are expensive, so it's better to avoid them if possible. Chances are
good that if you needed that memory before, you'll need it again.
Practically, this won't provide a problem because if it isn't used the
OS will just swap that page out to disk eventually and it'll be ignored
from then on.
Please note that all of this information is gleaned from somewhat
abstract discussions in classes I've had (pretty much my OS course),
and it's sometimes hard to tell if what we're learning is actually
things that are being done in practice or if there are better ways, and
almost all references to implementations in real systems (e.g. glibc)
are made in passing, so take what I said with a grain of salt.
- Next message: Mads Jensen: "Re: Does filename has to be the same as funtion name??"
- Previous message: eddy_ruslim_at_telkom.net: "Re: Adress of a struct vs address of its first field"
- In reply to: Richard Cavell: "Re: the different between aaa m1[100] and aaa *p = new [100]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
