NVIDIA Interview Question Software Engineer / Developers
Country: United States
Interview Type: Written Test
I concur, this is likely a case of overallocating memory for the expection of growth while the actual behavior is lots of small and compact memory chunks. Idealy a way to set the type of expected allocation would best. This way as you suggested, smaller, more compact blocks of memory could be handed out.
We can fix it by adding some kind of compaction. When average size of free block reaches some threshold - invoke compaction.
This suggestion is problematic; If I request memory via his memory manage with an interface like malloc(), you cannot possibly change where my pointers point to unless I free()ed or realloc()ed it as you'll be turning all my perfectly legal pointers into dangling pointer thus invoking undefined behavior.
Two considerations:
1. the coworker's memory usage pattern may be screwed by allocating too many noncontinuous memory blocks and leaving a large percentage of unallocated memory but cannot be utilized because of the external fragmentation.
2. the design of the memory manager you developed. This may be raised by the improper design of the memory manager by taking too much space for small allocated blocks. This design causes the internal fragmentation. For example, your design doesn't optimize the structure for small blocks allocated. If only 1 byte is allocated, but in order to maintain the alignment or meta information, you need to use another 15 bytes to satisfy the goal.
His memory usage pattern is probably skewed towards allocating a lot of small object (Hint Hint: heavy STL/BOOST usage). Tweak your memory manager to keep a lot of smaller size buffers available upfront.
- Anonymous October 09, 2013