Jump to content
  • Advertisement
Sign in to follow this  
Zipster

Efficiently tracking heap memory

This topic is 3790 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

Hello everyone, I'm currently working on some debug code that will track the range of virtual memory that the default heap has committed. We already track all our applications allocations, but I'd like to examine our fragmentation and get a better picture of how we're treating the heap. I'm basing my design off this article, and while it does a thorough job of explaining the process, there's too much hand-waving when it comes to elaborating on the "system calls" that make or break performance. I resorted to using HeapWalk() to track heap blocks whenever a commit/decommit occurs, however it's too slow to use even for debugging purposes (I need to lock/unlock the heap, use critical sections for accessing other data structures, etc). Long story short, I need a faster way of polling heap blocks for their state. That, or throw in some optimizations that allow me to speed up the search itself -- some way of caching information from previous searches or something along those lines perhaps. I also have a related question. The article suggests using IsBadReadPointer() for detecting decommits, however it's only available in purely debug builds. We have a few hybrid configurations that are essentially release builds without optimizations that we'd like to run the heap tracking code on as well, and this function isn't available. In lieu of IsBadReadPointer(), I'm just attempting to access the memory and catching any access violations. My question is, will there be any major performance difference between the two (the function call versus the exception catch)? I'm trying to determine if I need a faster way of detecting decommits as well. I appreciate any feedback, or suggestions from anyone who has tracked the heap before!

Share this post


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

  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!