Memory Management



  • I just have to vent about a coworker who wrote his own custom memory manager for an embedded linux system.  The beauty of this design is that he took a completely serial process and designed a multithreaded system to handle the serial process.  Next, instead of just using malloc and free to allocate dynamic memory, he wrote his own wrapper with one small catch, the memory manager was not threadsafe and each thread gets its own heap.  The beauty of the situation is that he decided to use indexes into the array as keys to keep track of the allocations.  What gets even better is that if you allocate memory on one thread and then free it on a second thread, depending on the index into the actual heap it may or may not corrupt the heap of the second thread.



  • What motivated him to even do this in the first place? Even under uclinux, malloc is re-entrant and threadsafe and everything (since it just maps to mmap/kmalloc). Was he hoping (at the outset) to do some kinda pooling of commonly used objects/sizes or something?



  • I like it.  He should write it so that it keeps reusing allocations of a particular size, but whenever there is no allocation of that size it gets a new block.  This way after the first few hours it gets a new block maybe only a few times an hour.  Then every time it can't get a new block it allocates a new chunk of virtual storage.  Then it can keep doing this for several days, or maybe two weeks.  Then when it runs out of address space it should go back and clean up all the unused memory, with several threads cleaning up the same or different allocation arrays all at once, each thread assuming it's the one and only.

    Everything will work great in QA.  Nobody will ever figure out what happens in production.  Solution:  reboot the production machine every two weeks.

     



  • @newfweiler said:

    Everything will work great in QA.  Nobody will ever figure out what happens in production.  Solution:  reboot the production machine every two weeks.

     

     

    God, I swear I have heard that one before. 



  • Excuse me if I am being naive...

    What did he write the wrapper in?



  • He is motivated by the fact that he is not a "big fan" of malloc/free calls on the embedded platform.  Much better to replace calls to a standard library that will "just work" with your own version that somewhat work under extremely limited circumstances.



  • @bhejl said:

    I just have to vent about a coworker who wrote his own custom memory manager for an embedded linux system.

    Yeah, it all sounds a bit WTF-ish. I'll just point out for fairness that there often are good reasons to write your own memory-management routines in embedded software. Of course, the person who writes the memory manager needs to know what he's doing, and have a really good reason for not using the standard heap-allocation routines. It looks like neither is the case here.

    On the other hand, I have worked on embedded systems that slowly ran themselves out of memory due to heap fragmentation, so "just use malloc(), you knucklehead!" isn't always the right answer, either. And there are certain environments where the use of dynamic memory allocation is strictly against the regulations. That's not a fun world to work in, either.


Log in to reply