[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libunwind-devel] Enhanced backtrace cache
From: |
Lassi Tuura |
Subject: |
Re: [Libunwind-devel] Enhanced backtrace cache |
Date: |
Mon, 24 Jan 2011 09:18:46 +0100 |
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