Re: Possible inline malloc alternatives: bitmap

[Ondřej Bílka <neleai at seznam dot cz>]

On Sat, Mar 03, 2018 at 03:37:45PM -0800, Carlos O'Donell wrote:
> On 03/03/2018 12:24 PM, Paul Eggert wrote:
> > I didn't quite follow your profiling proposals. As near as I can make
> > out you'd like to log calls to malloc, free, etc. But for good
> > results don't you also need to log memory accesses? Otherwise how
> > will you know which objects are hot?
> 
> We can already log malloc, free, etc. with the inlined tracing code we
> have on DJ's branch, and we in turn simulate those traces again.
> 
> You only need to log memory accesses if you want perfect reconstruction
> of the various memory subsystem effects. As you know this is obviously
> very expensive and difficult if not impossible to do. Some suggestions
> at LPC were provided though, including tracking heuristics or statistical
> profiles of hits/misses and trying to recreate those profiles in the
> page-touch heuristics used by the simulator (something it does when it
> gets a new block of memory).
> 
> Today we mostly use the simulator to look at in-use RSS, RSS max,
> and external and internal fragmentation, looking at trying to reduce
> that as much as we can.
> 
> Actually using it for profile driven feedback is very hard, and that
> kind of behaviour seems to be largely derived from first principles
> in most academic work.
>
No, just if you collect bunch of data unrelated to profiling you
couldn't be surprised that you couldn't use for profiling.

This impossible to do with trace, you could use trace only for
memory usage. Logging itself changes cache usage pattern which makes
everything considering cache inaccurate.

After that for profiling you need to gather completely different things, there is
zero overlap.

Here you knowing caller is essentional, you need to make decisions based on that.
Otherwise you would just find out that for one half you must do A, for
another B and don't know which part is which. 

Like I said measuring live time is easy as we need relatively low
precision. It would suffice to access variable that is increased each
1-2ms, accuracy doesn't matter that much.

Likewise cache properties when we do free are easy to get. Knowing if
chunks are still hot after specified time(like 10ms) after allocation
could be done by random sampling that marks some and if they weren't
freed we measure how long it takes to read data from them.

Here limitation is that we could do only certain number of reads before
they significantly change cache.