Anonymous user
Memory Allocation: Difference between revisions
→Tips to go further
| [unchecked revision] | [unchecked revision] |
(Added link) |
|||
Line 38:
* 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 <tt>free</tt> doesn't require the object's size. Normally this hidden header is kept just before the block returned by <tt>malloc</tt>.
* 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 host 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" ...
| |||