diff options
author | toma <toma@283d02a7-25f6-0310-bc7c-ecb5cbfe19da> | 2009-11-25 17:56:58 +0000 |
---|---|---|
committer | toma <toma@283d02a7-25f6-0310-bc7c-ecb5cbfe19da> | 2009-11-25 17:56:58 +0000 |
commit | ce4a32fe52ef09d8f5ff1dd22c001110902b60a2 (patch) | |
tree | 5ac38a06f3dde268dc7927dc155896926aaf7012 /kdecore/malloc/README | |
download | tdelibs-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/README | 56 |
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> |