Memory Allocation in Linux

vid, 2007-09-24Revision: 1.0

Many assembly programmers make linux applications using only syscalls, without glibc. Altough this way is usually considered bad practice, it is a fact.

One problem that pops out when using only syscalls is lack of managed dynamic memory (heap). Linux kernel doesn't provide any heap management. For most applications, that functionality is provided by glibc.

sys_mmap()

First option is to use sys_mmap() to allocate pages of memory. This approach has several problems.

Most apparent problem is that smallest block that can be allocated with sys_mmap() has 4KB. That is too much for most cases when allocation is needed.

Another problem is enlarging memory block. Dynamically allocated blocks sometime need to be enlarged. When enlarging block, sys_mmap() often has to move block to different place. That means all pointers to (and into) block has to be updated.

There is possibility to enlarge block without allowing system to move it, but that is very unrealiable way. It often fails and is practically unusuable.

Updating pointers may be sometimes hard, especially in assembly where using relative indexes to block wastes precious registers, and makes code a bit uglier.

These are two main reasons why sys_mmap() may not be right solution. There are also cases when sys_mmap() works fine, then it is okay to use it.

sys_brk()

Another possibility is using sys_brk(). This call is provided by kernel specifically to allow writing heap manager using it.

This call allocates memory right behind application image in memory. Memory is never moved, so you will never need to update pointers. There is plenty of memory behind image, and enlarging this block is safe.

Problem could be that you only have one such block. If you need to allocate more blocks, you need some custom memory management. Still, for applications that need only simple management, like single list of fixed-size structures, this is fine solution.

Existing heap managers

For any more complex application, neither method is good enough, and some more complex heap management is needed.

Most common way is to use glibc. This is good and easy solution.

Some assembly programmers doesn't like using glibc. For them, there is assembly library FASMLIB, which provides heap manager too.

Unfortunately, these two libraries cannot be used together, because they both use sys_brk() to allocate memory pool.

Custom heap manager

Some people prefer writing their own heap manager.

Custom specialized memory managers usually perform better than general-purpose managers, which must provide all functionality needed. When memory management is bottleneck of application speed, one should consider writing memory manager specialized for actual task.

However, writing a good general-purpose heap manager is a very complicated task. Especially if it has to support multithreaded application (that usually isn't case in linux, but still...). If there is a heap manager alredy written, that does what you need, then my advice is to stick to existing one.

lscr, linux syscalls reference and headers

glibc, GNU implemenentation of C standard library, provides heap management

FASMLIB, general purpose assembly library, provides heap management


Comments

Continue to discussion board.

You can contact the author using e-mail vid@x86asm.net.

Visit author's home page.


Revisions

2007-09-241.0First public versionvid

(dates format correspond to ISO 8601)