[computer-go] Language

[Petr Baudis]

On Wed, Nov 14, 2007 at 11:04:41AM -0500, Álvaro Begué wrote:
> On Nov 14, 2007 10:54 AM, steve uurtamo <apoxonpoo at yahoo.com> 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