Re: [Libunwind-devel] Enhanced backtrace cache

[Arun Sharma]

On Tue, Jan 04, 2011 at 04:17:16PM -0800, Jason Evans wrote:
> Last April, Lassi Tuura posted a patch series on this list that
> implements fast backtracing.  I enhanced his work to use a
> dynamically sized hash table, and to call user-specified allocation
> functions rather than malloc/free.
> 
> These changes allowed me to use the backtrace cache in jemalloc for
> the purposes of heap profiling, ,and the code has been stable for
> over six months now.  I would like to see these patches integrated
> into libunwind, so that the dependent changes to jemalloc can
> meaningfully be committed for a future release.

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

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

struct dwarf_rs_cache {...}. Perhaps we could generalize it and reuse. Allows 
caching policy to 
be configurable (none, global, per-thread).

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

--- a/tests/check-namespace.sh.in
+++ b/tests/check-namespace.sh.in
@@ -123,6 +123,9 @@ check_local_unw_abi () {
            match _U${plat}_is_fpreg
            match _UL${plat}_dwarf_search_unwind_table
            match _U${plat}_setcontext
+            match _UL${plat}_free_frame_cache

* off-by-1 problem

tests/Ltest-trace v:

Normal backtrace:
        fast backtrace:
         #0   ip=0x400db8
         #1   ip=0x40109e
         #2   ip=0x401cde
         #3   ip=0x401dd7
         #4   ip=0x7f99ec91cc4c
         #5   ip=0x400cc8

        via backtrace():
         #0   ip=0x400f6a
         #1   ip=0x40109f
         #2   ip=0x401cdf
         #3   ip=0x401dd8
         #4   ip=0x7f99ec91cc4d
         #5   ip=0x400cc9

Why not make it compatible?

 -Arun