On Wed, Nov 14, 2007 at 11:04:41AM -0500, Álvaro Begué wrote:
> On Nov 14, 2007 10:54 AM, steve uurtamo <[EMAIL PROTECTED]> wrote:
>
> > > I just wanted to point out that free() is not a system call. The heap is
> > handled by the
> > > C library, and the OS is mostly not involved in it.
> >
> >
> >
> > my bad. thanks. :)
> >
> > in that case, i'm impressed that i can do 2GB allocations.
>
>
> Well, the process has some memory assigned to it, and the C library will ask
> for more when it runs out (most likely when you allocate 2GB), but most
> calls to malloc() won't result in a system call, and I don't think a call to
> free() ever results in a system call. The details of how more memory is
> acquired depend on the platform. You can get a very good idea of how all of
> this works by reading section 8.7 of "The C programming language", by
> Kernighan and Ritchie.
For example on Linux (and probably most other UNIX systems), there are
two distinct syscalls that malloc() _might_ call to get memory from the
OS:
brk() - This increases data segment size of the program;
whatever is put inside the data segment is managed
by malloc() data structures and "small" allocations
typically get a chunk from the data segment
mmap() - This just asks the kernel for an arbitrarily-sized
block of memory; you can slam your header on the block
and then return it from malloc(). This is normally used
only for large allocations (like 128kb up) since it
rounds up the allocation to whole pages and making
a syscall has quite an overhead (you need to brk()
only rarely when the chunk does not fit in the already
requested data segment anymore)
Of course, this is heavily simplified.
--
Petr "Pasky" Baudis
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish. -- Marshall McLuhan
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
