Anonymous user
Memory Allocation: Difference between revisions
Jump to navigation
Jump to search
→Tips to go further: - suggesting sanity check that's helped me plenty.
| [unchecked revision] | [unchecked revision] |
m (→A very very simple Memory Manager: Corrected spellings) |
(→Tips to go further: - suggesting sanity check that's helped me plenty.) |
||
Line 37:
* Sometimes, and especially when you're working with objects, you have to allocate many objects that always have a certain size. It is wise to create pools of pre-divided large blocks for such objects.
* It's way easier to keep the size of allocated objects in a header hidden from the requester, so that a call to
* It's way easier to design a memory allocator in a host OS than in your kernel. Also, if you implement the full malloc interface (<tt>malloc</tt>, <tt>calloc</tt>, <tt>realloc</tt> and <tt>free</tt> is enough on Linux) a good sanity test is to compile your <tt>malloc</tt> into a shared library, then compile something (like your whole OS tree) with your malloc using LD_PRELOAD.
* Magic words like "F R E E" and "U S E D" will make your life easier when debugging. TimRobinson even allows 32 bits to store the address of the requester so that you can see "okay, this is a N-bytes block that was requested by <tt>MySillyFunction()</tt>, line 3405" ...
| |||