OSDev.org

I'm confused, now that I've got multiple processes running within my OS, I'm wondering just where the memory for a process calling malloc() comes from. Could someone break it down to me how execution flows after a malloc() call?

well, 'malloc' actually allocates *virtual* memory. It has its own internal lists for reusing recently freed blocks and (in unix style, at least) calls "more_core()" to extend the "heap" area when it cannot successfully grant a request.

Receiving "more_core()" at kernel level simply require you to change process's regions descriptions and to change the state of some page from "invalid" to "automatically allocate a zero'ed page" ...

When you actually need a page (some may be pre-loaded) in that newly-activated region, you take a lock on the physical memory manager, request one (or more) free pages and unlock then write page address in tables.

HTH

So malloc() is something that I don't need to implement until I focus on writing a glibc equivalent, but when I write it I also need to have a kernel component that will interpret the more_core() function?

That seems to be pretty far away, as of yet, but how big of blocks are we talking with this malloc()? I know that my kernel heap allocated with respect to integers, would this be much the same thing?

wangpeng wrote: how big of blocks are we talking with this malloc()? I know that my kernel heap allocated with respect to integers, would this be much the same thing?

? ? ?

Nevermind, stupid question... 7 in the morning right before class, don't worry about it. But the first part was right?

wangpeng wrote: So malloc() is something that I don't need to implement until I focus on writing a glibc equivalent, but when I write it I also need to have a kernel component that will interpret the more_core() function?

Indeed. Now, an independent issue is whether you need a malloc-like service for kernel's own needs and how to implement that service ...