summaryrefslogtreecommitdiffstats
path: root/kdecore/malloc/README
diff options
context:
space:
mode:
authortoma <toma@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2009-11-25 17:56:58 +0000
committertoma <toma@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2009-11-25 17:56:58 +0000
commitce4a32fe52ef09d8f5ff1dd22c001110902b60a2 (patch)
tree5ac38a06f3dde268dc7927dc155896926aaf7012 /kdecore/malloc/README
downloadtdelibs-ce4a32fe52ef09d8f5ff1dd22c001110902b60a2.tar.gz
tdelibs-ce4a32fe52ef09d8f5ff1dd22c001110902b60a2.zip
Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features.
BUG:215923 git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdelibs@1054174 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Diffstat (limited to 'kdecore/malloc/README')
-rw-r--r--kdecore/malloc/README56
1 files changed, 56 insertions, 0 deletions
diff --git a/kdecore/malloc/README b/kdecore/malloc/README
new file mode 100644
index 000000000..181c29764
--- /dev/null
+++ b/kdecore/malloc/README
@@ -0,0 +1,56 @@
+
+ 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 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>