In just about every single job interview I've ever had, they have asked me, "What do you do about memory management?" I tell them that I've personally never had a problem with memory management, and I always "delete" whatever I "new". But I KNOW that that's not the answer they're looking for! :D So what is the "correct" answer? Should I go on and on about managed memory and garbage collection? Managed C++? C#?

You can say something about RAII (http://en.wikipedia.org/wiki/RAII) and SC++L allocators. In properly written C++ programs you very rarely use the delete keyword.

There is not really a correct answer, but what you should demonstrate is your understanding of the subject.

Sayin something like you are aware of the potential for memory leaks by explicitly using delete. State that you are aware that the stl contains some solutions for smart memory management (auto_ptr) but also that other libraries such as Boost offer more useful solutions (scoped_ptr, shared_ptr etc.).

If you don't know about these then i would be good to learn about them, not just for interview purposes but also for your own programming.

"What do you do about memory management?" is kind of a vague question. Do they mean in context of making your own memory manager or using the OSs? Or do they mean what syle of resource cleanup resources do you use? IMO it's like asking "what do you do about files?".

If I were asked that question I would follow it up with a clarifying question before answering.

I hate questions like this. "What do you know about universe?" ....

- Memory chipset memory bank organization. Memory hierarchy and why it matters. Costs of reading and writing. latency vs. throughput. Different memory layouts on today's multi-core chipsets with regards to L1/L2 cache. All important when organizing memory.

- OS and virtual memory. Per-process memory allocation (how process memory is mapped to physical and virtual, costs of paging), memory protection, OS-specific details such as paged/non-paged memory. These are important to manage OS resources, sockets, handles, files, graphics, sound, kernel resources. A simple static array[] definition in DLL can exhaust OS-provided memory, although same code would work as a standalone application. Why a server can report out of memory although it's only using a 6 MB of system memory. How OS protects you from resource leaks.

- Each language's own memory management. If memory managed, the GC design and algorithms, if not, the language's own allocation routines or common algorithms.

- Theory. Address translation, caching strategies, handles vs. pointers, static vs. dynamic (char *c vs. const char *c vs. std::string - differences), alignment, allocation strategies (how do new and malloc work), behavior of data structures, memory fragmentation, pitfalls of allocations in threaded environment, ...

And then comes the big part, the application level memory/resource management. How do you manage those as a whole, ....

Memory management is simply a too complex topic to be answered in such a generic manner.


If this is for C++, then you should be able to explain (these are just everyday concepts):
- new/new[]/delete/delete[]/malloc/free
- difference between auto and freestore allocation (why and why not these are stack/heap)
- std::allocators
- cache locality
- member memory alignment
- pointers vs. references
- buffer over/underrun, dangling pointers, double deletionsmart pointers (different strategies), what is NULL pointer and why it really isn't
- give a quick demonstration of a custom pooled allocator (templated/static vs. stateful/fixed size vs. growing)
- pass by-value/by-reference
- memory layout of classes
- exception safe rule of three
- shallow vs. deep copy
- static order initialization fiasco
- language specific problems with singletons
- how are (static) members allocated across different compilation units

For managed languages you should know:
- how GC works, when it triggers, approximate costs
- which members are "stack" allocated and which are managed
- boxing (costs)
- global heap limits
- memory leaks (why they occur), show on List/Vector example
- strong/weak references
- identity vs. equality
- immutability

And I'm sure I've forgotten more than I've listed.

Quote:Original post by yaustar
Would referring to memory fragmentation be applicable here?

Yes, as well as how it applies to default/custom memory allocation vs. memory managed languages (note that not all MM languages use same method, so it's not universal). It's also related to data locality and data alignment.

One could also mention why using the stack is beneficial, as well as perhaps mentioning various optimal or perfect allocation strategies for various data structures (millions of strings with lengths between 1 and 5000), trade-off of allocation cost vs. memory use. One can even discuss how to implement defragmentation.

It's also possible to compare memory fragmentation to disk fragmentation, and point out why fragmentation on disk (under applicable file systems, obviously) does not reduce total available space, whereas in memory it can, and what the cost for this "feature" is, and how it can be applied to memory allocations.

But at very least one should know what fragmentation is and why it can be a problem.

Thanks for the answers!

Actually, I have been asked this question, in exactly this form of vagueness. One time, though, they did get specific, and asked me how I would find memory leaks in a huge program that had thousands of new and delete operations.