initial import from hack-malloc

Source: https://github.com/wware/stuff/tree/master/hack-malloc

Author: jserv

FreeRTOS.h

@@ -0,0 +1,31 @@
+/*
+ * Fake values for convenient testing of defrag code.
+ */
+
+#include <stdio.h>
+
+#define ALIGNMENT_BITS 2
+#define portBYTE_ALIGNMENT      (1 << ALIGNMENT_BITS)
+#define portBYTE_ALIGNMENT_MASK (portBYTE_ALIGNMENT - 1)
+#define configUSE_MALLOC_FAILED_HOOK 0
+#define configTOTAL_HEAP_SIZE 4096
+#define pdFALSE 0
+#define pdTRUE 1
+
+typedef int portBASE_TYPE;
+
+#define vTaskSuspendAll()
+#define xTaskResumeAll()
+
+#ifdef ENABLE_DEBUG
+#define DBGPRINTF(x)          printf("%s %d: ", __FILE__, __LINE__); printf(x)
+#define DBGPRINTF1(x,a)       printf("%s %d: ", __FILE__, __LINE__); printf(x, a)
+#define DBGPRINTF2(x,a,b)     printf("%s %d: ", __FILE__, __LINE__); printf(x, a, b)
+#define DBGPRINTF3(x,a,b,c)   printf("%s %d: ", __FILE__, __LINE__); printf(x, a, b, c)
+#else
+#define DBGPRINTF(x)
+#define DBGPRINTF1(x,a)
+#define DBGPRINTF2(x,a,b)
+#define DBGPRINTF3(x,a,b,c)
+#endif
+

Makefile

@@ -0,0 +1,8 @@
+CC = gcc
+CFLAGS = -g -Wall
+
+tryit: tryit.o heap_ww.o
+	gcc -o tryit tryit.o heap_ww.o
+
+clean:
+	rm -f *~ *.o tryit

README.rst

@@ -0,0 +1,48 @@
+Fooling around with memory allocation
+=====================================
+
+Memory allocation is one of those classically hard problems of computer
+science, or so I had been led to believe. So imagine my surprise when I came
+across a really simple elegant memory allocator as part of the FreeRTOS
+operating system.
+
+http://code.google.com/p/lumweb/source/browse/trunk/src/external/freeRTOS/Source/portable/MemMang/heap_2.c
+
+The free list is maintained as a linked list of blocks in order of increasing
+size. The malloc() function steps through them, looking for the first one
+large enough to accommodate a request. If the block is larger than the request
+by a sufficient margin, it is split into two blocks, the first one returned,
+and the second kept in the free list. When a block is freed, it is returned to
+the free list, retaining the ordering by block size. This is done by the
+prvInsertBlockIntoFreeList function. Each block begins with a struct
+containing the next-pointer for the size-ordered linked list, and a byte
+count. The allocation (the pointer returned by malloc) comes right after
+the struct. There are likely to be word alignment issues to think about, for
+example I am planning to use this on a 32-bit architecture so the smallest
+possible allocation would be four bytes.
+
+It's quite ingenious but it's prone to fragmentation. If you have lots of very
+small allocations they can chop the heap into small pieces, so that a later
+large allocation request is unnecessarily denied even though there is really
+enough free memory to serve it.
+
+I've got an idea for defragmentation which I will be tinkering with here. The
+idea is that when you free a block, you look at the immediately preceding and
+following blocks, not in order of increasing block size but in order of
+physical memory address, and you look to see, what is the largest contiguous
+block I can reassemble right now? If two or more blocks are contiguous (they
+have zero bytes between them) then they can be merged into one big block.
+
+A couple of minor details. The struct at the beginning of each block will need
+one more next-pointer for the ordering by physical address. The time spent in
+free() will be a little more, and during that time, any thread that might want
+to call malloc() or free() will need to be suspended (as is done in FreeRTOS
+already).
+
+I plan to try implementing this and writing some tests to see if it works as
+well as I hope. In particular it should be possible to do the worst-case thing
+above of many small allocations followed by one very large allocation. If it
+passes tests, I'll suggest it to the FreeRTOS folks as an alternative to
+heap_2.c.
+
+source: https://github.com/wware/stuff/tree/master/hack-malloc