YetiSim Blog

As discussed in my previous blog, YetiSim’s memory management has formed a bottleneck.  I’m not entirely sure how to deal with this problem, so I’m considering abstracting the problem by creating a helper class called MemoryManager.  This would form  a common interface for memory management within YetiSim.  Hence future enhancements could be hidden behind a well defined interface.  Also, I think that issues of parallelism could be better handled in one place.

This would mean migrating from boost::shared_ptr to just regular old pointers.  This should be exception safe, because the MemoryManager is responsible for creating and deleting objects.  Hence, if an exception is thrown memory should not be lost because the MemoryManager class could be used to recover it, or to delete it if not required.  A memory pool could easily be implemented with the class, and the complexities of memory management could be entirely abstracted.

The MemoryManager would be implemented as a singleton class, just like the MasterScheduler.

Another possible advantage of abstracting memory management, is the migration of YetiSim to execution on clusters.  I’m not a cluster expert, however I know that managing memory that is spread across clusters would be different than managing the memory of a single computer.  One of the primary goals of YetiSim, is to be able to take a simulation from a single computer to execution on a large cluster.  This is a topic for another blog, but this longterm goal adds support to the argument for implementing a class to abstract the memory management.

I’m going to work on designing the memory management class tonight, and implement as much of it as possible.