This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Dynamic memory allocation primitives.


I have been thinking about low level memory allocation primitives for malloc(3), et. al.  More specifically, I have a program (as this is better for experimenting with ideas), in the attached TAR file, that implements and uses such primitives, and feel that these might potentially be used in the glibc implementation of the malloc mechanism --- probably with modification and refinement.  I think that this approach would completely avoid memory arena fragmentation in long running processes, such as daemons.  I also am open to the possibility that this approach might also have problems of its own.

In the included source code, you will find a file called malloc.c, that implements malloc_blk, etc. that manage mmap(2) obtained blocks of memory and maintains block size data in a data structure not unlike CPU page tables.  Moreover, in the file slab.c, you will find a free list oriented manager of an array of objects of the same size (which, in general usage, would probably an array of objects of the same type).  Although not currently implemented quite as such, I was wondering if it would be a feasible design strategy to have an implementation of malloc(3), etc., that has an array of slabs, for sizes of say 8, 16, 32,..., 1<<n, and then use the *_blk interface when the block is malloc'ed or realloc'ed to sizes larger than 1<<n.

Before continuing this project, I would like to know how feasible this overall approach would be, and, if so, how usable this would be in a general purpose code library, such as libc.


Attachment: memory-allocation.tar
Description: Unix tar archive

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]