Jump to content
  • Advertisement
Sign in to follow this  
CTar

Memory management system

This topic is 3754 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

During work on a C++ application I found the need for a specialized allocator to battle fragmentation, false sharing and to improve data locality. I've tried generalizing the idea a bit, and have considered making a general-purpose library providing the functionality, but before I code it I would like some feedback on it (both on whether it has been done before and whether it has disadvantages I haven't considered). It relies on the idea that the programmer has lots of information on the logical structure of the program which the memory management system can utilize to structure memory efficiently. Instead of manually trying to structure memory, we tell the memory management system how it will be used. The user is able to construct a nested hierarchy of allocation domains, and can attach special properties to each domain. For instance we may tell some domains that all memory is freed at once (often known as an arena or region), or how much the peak memory consumption will be, or perhaps we will tell it whether it will be accessed from several threads or a single one. Using this data we can do some strategic planning, instead of determining online as the allocations come in. There is also the fact that there is data locality within a domain, so we can get good spatial locality. It should be fairly intuitive to create domains as you develop your application, and it might even make your code a bit more self-documenting. It should also be noted that specifying all properties can be left out if you think it's too much hassle. Then if your profiler later on tells you that you have problems in some sections of code, you can experiment with properties. I would love to get some feedback on the idea, or get links to other systems.

Share this post


Link to post
Share on other sites
Advertisement
So, basically, you're going to have an allocator factory that will pass out allocators according to the information you give it, and then you will build allocators that better fit various usage patterns.

It sounds good to me. The only suggestion I'd make is that you implement the type selection using template metaprogramming as much as possible (ie for usage pattern information, but not for numeric information such as maximum memory usage) so that you can efficiently use it with the STL. You should know the usage pattern information at compile-time for the most part, and if not you could always make a factory class that wraps the various template instantiations.

On the other hand, you could just create the different allocators and use them as you will - the only reason to make a factory / type selection is to make the selection system extensible - so that the code will automatically pick a better allocator if you add one that matches a specific set of usage parameters more closely.

Share this post


Link to post
Share on other sites
Quote:
Original post by Extrarius
So, basically, you're going to have an allocator factory that will pass out allocators according to the information you give it, and then you will build allocators that better fit various usage patterns.

Yes, that's the general idea.

Quote:
It sounds good to me. The only suggestion I'd make is that you implement the type selection using template metaprogramming as much as possible (ie for usage pattern information, but not for numeric information such as maximum memory usage) so that you can efficiently use it with the STL. You should know the usage pattern information at compile-time for the most part, and if not you could always make a factory class that wraps the various template instantiations.

I will certainly use template metaprogramming, and while I will try to encourage compile-time decisions I will allow extensions that make the decision at runtime.

Quote:
On the other hand, you could just create the different allocators and use them as you will - the only reason to make a factory / type selection is to make the selection system extensible - so that the code will automatically pick a better allocator if you add one that matches a specific set of usage parameters more closely.

Given a properly designed library the different components will be composeable. You could for example create an allocator that took a template argument telling your allocator the average number of allocations, but it may be more suitable for the user to provide a description of the distribution of allocations over time. Traditionally you would either force the user to use your format, or have to change your allocator (which may be third-party with license restrictions). Using a library it should be a simple matter of creating a filter converting from a distribution function to an average number of allocations.

These kinds of helper constructs, and the provided allocators makes the library more attractive.

Share this post


Link to post
Share on other sites
One extremely useful feature would be providing a generic instrumented allocator that could replace any other in the library that would gather and log the relevant statistics instead of utilize them. During development and testing, a flag is set by the library user and suddenly all the allocators become the instrumented version for generating statistics, and then for public builds, that information is compiled by a provided utility that then suggests appropriate types and parameters that should optimize performance.

Share this post


Link to post
Share on other sites
Quote:
I would just like to point out loki and the policy class design pattern. Sounds interesting.

Thanks for the suggestion. I did plan to make much of it policy-based, though I doubt I will actually use Loki (most of the useful functionality is also available in Boost).

Quote:
Original post by Extrarius
One extremely useful feature would be providing a generic instrumented allocator that could replace any other in the library that would gather and log the relevant statistics instead of utilize them. During development and testing, a flag is set by the library user and suddenly all the allocators become the instrumented version for generating statistics, and then for public builds, that information is compiled by a provided utility that then suggests appropriate types and parameters that should optimize performance.


That is a pretty good idea. Thanks. I had considered letting observers attach themselves to allocators to create statistics and allocation traces, but I hadn't considered using them for giving the user advice.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!