Anonymous user
Memory Allocation: Difference between revisions
Added links and article references
| [unchecked revision] | [unchecked revision] |
No edit summary |
(Added links and article references) |
||
Line 1:
:''This page is about the allocation of memory from memory that is already available to the process (like malloc() and new()). For the allocation of page frames see [[Page Frame Allocation]].''
One of the most basic functions of a [[Kernels|kernel]] is the [[Memory Management|memory management]], i.e. the allocating and freeing of memory.
At square one, the kernel is the only process in the system. But it is not alone: [[BIOS]] data structures, memory-mapped hardware registers etc. populate the address space. Among the first things a kernel must do is to start bookkeeping about which areas of physical memory are available for use and which are to be considered "occupied".
The free space will subsequently be used for kernel data structures, application binaries, their heap and stack etc. - the kernel needs a function that marks a memory area as reserved, and makes that memory available to the process requiring it. In the C Standard Library, this is handled by malloc() and free(); in C++ by new() and delete().
Line 37:
* Sometimes, and especially when you're working with objects, you have to allocate many objects that always have a certain size. It is wise to create pools of pre-divided large blocks for such objects.
* It's way easier to keep the size of allocated objects in a header hidden from the
* It's way easier to design a memory allocator in a host OS than in your kernel.
* Magic words like "F R E E" and "U S E D" will make your life easier when debugging. TimRobinson even allows 32 bits to store the address of the
==Memory & Microkernels==
In a [[Microkernel|microkernel]] environment, there comes up a question: where the hell shall I put the memory management? In sense of heap management: give the kernel a dedicated allocator and a dedicated memory area to use - you might need two of them: one for the messages, and one for all the other stuff.
The other task of memory management: Process address space management, keeping track of used pages (yes, lets talk about paging, it is nice, it is neat, it causes a warm fuzzy feeling beneath the toes) and assigning memory to processes as needed, you can split it up. To be more precise, you have to split this task up - or keep every aspect of memory management in kernel land to make it easy. A recommended method for managing process address space: handle it in a per-process-manner. The actual process needs memory: allocate the memory and hand it out to the process. So you can keep the page allocating routines easy and straight forward. For this task of allocating/deallocating memory, you should take into consideration, that the task performing such actions should be able to slip into
==External Links==
*[http://www.cs.hut.fi/~tvoipio/memtutor.html Basic VMM]
*[http://www.osdever.net/tutorials/memory1.php?the_id=44 Memory Management 1] - Part one of a two part series on memory management by Tim Robinson
*[http://www.osdever.net/tutorials/memory2.php?the_id=45 Memory Management 2] - Part two of a two part series on memory management by Tim Robinson
[[Category:Memory Management]]
| |||