[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <002401cc0f76$dc25e3d0$9471ab70$@net>
Date: Tue, 10 May 2011 20:00:45 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: single mode problem
>From: Solar Designer Sent: Tuesday, May 10, 2011 6:43 PM
>...Oh, here's a better idea. We could introduce a way to revert all
>mem_alloc_tiny() allocations up to a certain saved state. This is in
>line with JimF's work on being able to detect unintended memory leaks.
>Perhaps I will just implement that.
That actually should be pretty easy to add. It would be helpful for me
also, in tracking down memory leaks. Right now, I can only do that at the
very end. But if I could snap a memory state, then restore it (for the
mem_alloc_tiny() function), I could easily check the heap prior to an
unknown call, save a mem marker, make the call, restore the mem marker, then
check to see if the heap is the same (looking for leaks).
But this may be along the same line. It might also work, to create a
'named' mem_alloc_tiny pool allocator. Then a set of work could own it's
own allocation pool, and when done with it, simply release the entire pool.
There would be the default 'global' poop we have today with mem_alloc_tiny,
but add another mem_alloc_named(name,size,align) along with a
free_alloc_name(name), and possibly mem_alloc_named_setup(name,blocksz).
Hash the name, and it should be pretty fast, but would allow having your own
localized tiny aligned memory allocator. It could even speed things up, by
reducing the working set for some formats.
Good thoughts.
Jim.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
