|
Message-ID: <20180830184653.GU1878@brightrain.aerifal.cx> 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.