Re: [Libunwind-devel] [PATCH 0/1] Fast back-trace for x86_64 for only collecting the call stack

[Lassi Tuura]

Hi Arun,

> I'm a bit behind on libunwind related emails/patches, but hope to look
> at your patch in more detail in the next week or so.

Thanks. There's no great urgency, but obviously if we can avoid a patch,
it's better for us.

> I generally like the idea of having a fast back trace with a fall back
> to a correct, slower, but more general case. A couple of initial
> comments:
>
> * Why not use a call back based API instead of a backtrace() style API?
> For eg:

I don't have a strong opinion. All we need is the stack trace, and I
suspect there are other similar clients, so callback isn't necessary. We
mainly care about making the walk loop as fast as possible since we call
into it million times a second. (Or would, if it was fast enough :-))

> * I couldn't tell what is the locking protocol on the frame cache. In
> the multi-threaded case, do you expect to have a global frame cache or
> a per-thread frame cache?

As designed, there's no locking and the caller must ensure the frame cache
is not used by any other thread at the same time. The reason for us is
that we want to ensure maximum performance, and our current main users
don't create so many threads this would be a problem. Also our profiler
traps thread creation so it's trivial to set up thread specific caches.

I'd be interested how others might desire from a fast walk; the above are
just our biases. I imagine the cache could have other uses, it might
significantly accelerate ptrace-based walks for example. If we know what
people want we have a better chance judging which aspects can be satisfied
by a single API.

Regards,
Lassi