You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
tdelibs/tdecore/malloc
Timothy Pearson e16866e072
Actually move the kde files that were renamed in the last commit
13 years ago
..
CMakeLists.txt Actually move the kde files that were renamed in the last commit 13 years ago
Makefile.am Actually move the kde files that were renamed in the last commit 13 years ago
README Actually move the kde files that were renamed in the last commit 13 years ago
configure.in.in Actually move the kde files that were renamed in the last commit 13 years ago
glibc.h Actually move the kde files that were renamed in the last commit 13 years ago
malloc.c Actually move the kde files that were renamed in the last commit 13 years ago
x86.h Actually move the kde files that were renamed in the last commit 13 years ago

README

 This malloc is based on Doug Lea's malloc ( ftp://gee.cs.oswego.edu/pub/misc/ ), the changes
are listed below. See http://lists.kde.org/?l=kde-core-devel&m=101351949010285&w=2 for details.
Basically, it's here because for now it has better performance than both glibc-2.2.x and
FreeBSD's libc.

 There's a new configure switch, --enable-fast-malloc. By default it's turned off, disabling
the system libc one and using this one. Using --enable-fast-malloc=full enables this
malloc unconditionally, aiming for the maximum performance. By using only --enable-fast-malloc,
it's possible to select both malloc implementations at runtime. When $KDE_MALLOC is set to 0,
the system libc malloc is used, otherwise this malloc is used.

 For now, the requirements are :
 - x86 CPU (because of the spinlock implementation in assembler), it should be easy to add
   new ones
 - glibc (for --enable-fast-malloc=yes, =full doesn't need it), because it needs to refer
   to the libc implementation of malloc (__libc_malloc etc.)
 - gcc (for __inline__ , nothing else should depend on gcc)


 If you have any problem with this malloc, try first using --enable-fast-malloc=debug and
recompiling libtdecore, or use valgrind. This malloc seems to be more vulnerable to heap
corruption, such as deleting a block twice, so faulty code may run without problems
with standard malloc shipped with your libc, but it will crash with this malloc. In case
you think there's any problem with this malloc, please mail me.

changes (against malloc-2.7.0):

#define USE_MALLOC_LOCK
#define INLINE __inline__
#define USE_MEMCPY 0
#define MMAP_CLEARS 1
made all functions INLINE
added #ifdef KDE_MALLOC_DEBUG -> #define DEBUG
reordered all functions in order to avoid 'warning: `XYZ' declared inline after being called'
    especially moved the public_* ones at the end of the file
commented out #including malloc.h
added #include <config.h> at the top and enclosed whole file in #ifdef KDE_MALLOC
taken posix_memalign() from glibc
removed public icalloc(),icomalloc(),mtrim(),musable()  (they don't exist everywhere anyway)
enclosed the pthreads part by #if 0 and replaced it with spinlock from glibc CVS (in x86.h)
    also added :
----------
static mutex_t spinlock = MUTEX_INITIALIZER;
#define MALLOC_PREACTION   lock( &spinlock )
#define MALLOC_POSTACTION  unlock( &spinlock )
----------
public functions call either functions in this malloc or in libc, depending on $KDE_MALLOC
the kde_malloc_is_used hack


TODO:
malloc_set_state/malloc_get_state ?


Lubos Lunak <l.lunak@kde.org>