Re: [Libunwind-devel] Enhanced backtrace cache

[Lassi Tuura]

Hi,

Sorry for dropping out for a while on this. I am very happy to hear about 
Jason's improvements. I'll test his version in our profiler later this week.

> The feedback I've received about Lassi's patch has been overwhelmingly
> positive. I'm trying to figure out the best way to merge while covering
> all the use cases.
> 
> A few comments:
> 
> * The API is very similar to backtrace() - so why not use backtrace() itself?
> 
> I suspect that the main reason is that unw_tdep_make_frame_cache() calls 
> malloc, which is why the cache is being allocated statically, before 
> unwinding begins. We could avoid that problem by using the mempool API.
> 
> But then I see that your second patch uses malloc callbacks. Does it work 
> with malloc implementations
> that get upset when called recursively?
> 
> malloc -> heap_profiler -> backtrace() -> cache management code -> malloc

Hm, yes. I agree it's a constraint which might better be relaxed, though nested 
calls are not a problem for our specific profiler. I suspect Jason's callbacks 
use mmap().

I can try to have a look if I can tweak to use the mempool API ~ Friday this 
week.

Concerning backtrace() API, the major considerations I had was whether others 
would be surprised if it retains large hidden persistent state, especially if 
it does that in every thread it's called to meet the performance objectives.

> * There is a cache implementation that I lifted from src/ia64 
> (ia64_script_cache) several years ago [...]

I promised to take a look at this, so I'll finally do that later this week.

> * This will break other archs unless they provide no-op stubs to implement 
> the same API

Should the 'fast trace' be missing if there is no optimised version? Or should 
we try to implement it for other archs? Should it fall back on slow trace?

I could look at fast trace for IA32 for Linux/BSD. I don't have access to other 
archs though. I know something about MIPS and PPC, but precious little about 
IA64 or ARM.

> * off-by-1 problem

Is one of these missing the interrupted vs. called distinction? Which 
backtrace() did you use, one libunwind or system one?

Regards,
Lassi