[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 30 Aug 2018 14:46:53 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: malloc implementation survey: omalloc
On Thu, Aug 30, 2018 at 01:16:27PM -0500, A. Wilcox wrote:
> On 07/30/18 20:44, Rich Felker wrote:
> > One thing that would probably be really useful is empirical data on
> > what range of sizes "need to be fast" for bloated OO stuff that does
> > rapid malloc/free cycles. Conceptually it should only be small sizes,
> > assuming the whole allocated space is actually used, since beyond a
> > certain size, actual use of the allocated memory (loads/stores) will
> > dominate the time spent allocating and freeing it, but the cutoff
> > isn't clear.
>
> I can probably instrument the malloc() patterns of Firefox and Plasma
> Shell. Can you provide me the desired format?
>
> I would probably simply change musl to print "a:%lld\n" to stderr for
> each allocation, and then I could turn it into better formatted data.
In order to measure lifetime/life cycle, you need an identifier to tie
realloc/free back to the allocation. Printing the resulting pointer
value should work, but then I think you'd want to postprocess the file
to add unique sequence numbers (or just replace the pointers with
sequence numbers) so that subsequent reuse of the same address
wouldn't get associated as the same allocation. Timestamps might be
useful to in order to measure the lifetime not just in terms of number
of intervening allocations but actual wall clock time.
In order to make any of this perform acceptably and somewhat (though
nowhere near entirely) reduce instrumentation noise, I think you'd
want to write in binary form and heavily buffer (buffered stdio/fwrite
would not be bad, or you could roll your own).
Rich
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.
