On Jun 8, 2010 , at 3:05 PM CDT, Alex Slover wrote:
> Hello-
>
> I'm using the custom memory pool macros for the first time, and though
> I've read through all of Memcheck's documentation, there are a few
> questions I'm still not quite clear on. I'd also like to explain my
> custom memory allocation scheme, and how I'm planning on "tagging" it,
> so someone can help me if there are any glaring mistakes. In
> particular:
>
> 1. What is the relationship between the valgrind MALLOC/FREELIKE_BLOCK
> and Memcheck-specific MEMPOOL_ALLOC functions? If I'm carving out a
> chunk of memory, do I need to call them both? Also, am I correct in
> assuming that these functions take care of marking the memory as
> defined/undefined/noaccess?
IIRC, you should use one or the other. Also, I remember that (in the past at
least) you can't use MALLOC/FREELIKE_BLOCK on memory returned from the system
malloc/free functions. I never tried with mmap'ed memory, but I'm sure someone
else on the list knows whether this works. You could also find out pretty
quickly with a small test program.
> 2. I understand that I should use MAKE_MEM_NOACCESS to mark sections
> of memory that are used internally by the allocator, but won't this
> cause Memcheck to find errors whenever the allocator changes its own
> state? How does Memcheck know the difference between the allocator
> code and client code? Should I use VALGRIND_DISCARD for this?
Valgrind doesn't have any magic way to tell what accesses are made by the
allocator and which are made by the client code. You have to twiddle regions
appropriately via the MAKE_MEM_{NOACCESS,UNDEFINED,DEFINED} requests to prevent
valgrind from warning about valid accesses by the allocator. This is what I
did when I added valgrind client requests to the MPI handle allocator in MPICH2.
I think DISCARD is only for telling valgrind that it should stop keeping track
of the description you gave it via CREATE_BLOCK.
> 3. Am I correct in assuming that CREATE_MEMPOOL only registers a pool
> and its base address with valgrind? It doesn't change the layout of
> memory at all?
No layout of memory is changed, AFAIK. You are just telling valgrind that you
will use this address as a handle for grouping MEMPOOL_ALLOC/FREE requests.
> =====================================
>
> The custom allocator setup is as follows:
>
> When the allocator is created, a large "arena" is malloc'd. The arena
> has a brief descriptor. For each object type that you wish to store in
> the arena, a pool is created. Pools may consist of one or more blocks
> (of constant size), and each block can hold a certain number of
> frames, one frame per object. For each pool, one block is the "home
> block" which contains descriptors for both the pool and the block,
> other blocks just have a block descriptor. Thus, when you wish to
> allocate space for an object, the pool associated with that object
> looks through its blocks for a free frame. If none are left, it
> creates a new block for that pool.
>
> My plan was thus:
>
> - When the arena is created, mark the entire space as NOACCESS
> - Each block (not pool) corresponds to a MEMPOOL, so whenever a block
> is created, CREATE_MEMPOOL is called
> - When an object is allocated, MEMPOOL_ALLOC is called, and
> MEMPOOL_FREE is used when it's freed
>
> Does this seem reasonable?
Seems reasonable enough. My understanding is that the MEMPOOL is just there to
group objects in a way that makes sense to you. So if it makes more sense to
group them by block instead of pool, then do that. However, since you have
some pool-common bookkeeping information in the "home block" of each pool, I
think I would personally create a MEMPOOL for each pool.
-Dave
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
