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/kdecore/malloc
tpearson 560378aaca
Automated conversion for enhanced compatibility with TQt for Qt4 3.4.0 TP1
14 years ago
..
CMakeLists.txt [kdelibs] added initial cmake support 14 years ago
Makefile.am Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features. 15 years ago
README Automated conversion for enhanced compatibility with TQt for Qt4 3.4.0 TP1 14 years ago
configure.in.in Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features. 15 years ago
glibc.h Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features. 15 years ago
malloc.c Automated conversion for enhanced compatibility with TQt for Qt4 3.4.0 TP1 14 years ago
x86.h Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features. 15 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 libkdecore, 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 tqreplaced 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>