The cost of stack traces

Wed May 10 22:20:00 GMT 2006

On May 10, 2006, at 2:01 PM, David Daney wrote:
> Casey Marshall wrote:
>> Something I wanted to do in the DWARF reader I wrote (but never 
>> did, since the patch wasn't accepted) was to cache *approximate* 
>> information about where to look for debug info for an address. So 
>> you'd have a range of PC values that would map to regions in 
>> the .debug_line section where you would find the debug info you 
>> were looking for. That would probably help lookup times, at least 
>> in a long-running application, and the map wouldn't need to 
>> contain too much data.
>> The big slowdown, from what I can tell, is that you have to scan 
>> from the very beginning of the debug info to find the address, 
>> and that can be slow for huge libraries like libgcj. You could 
>> probably optimize the hell out of this, by scanning a library 
>> just once and building a good, approximate cache of where to look 
>> things up.
>> Shall I post my patch for this again? :-)
>> I, for one, would like very much to see the patch again.
>> What were the reasons that it was not accepted?
>
I seem to recall that since it didn't support anything bug 32-bit 
ELF, it was considered too limited. But, that limitation isn't 
inherent; you could build up the same framework for other 
architectures and formats.
I don't think it was a strong "no." It kind of just fell off the 
radar, and I had disappeared for a while at the time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 478 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/java/attachments/20060510/5f7ac3b7/attachment.sig>