The cost of stack traces

[Casey Marshall]

Well, I did some experimenting with building a lookup table for my  
DWARF-2 reader, such that you can look up an address and get the  
compilation unit where that address is mapped to debug info, and the  
results look really good!

I'm running this on Sun's 1.5.0 VM on Linux, and it only takes 161 ms  
to scan libgcj.so, and that builds a cache with only 421 entries (I  
haven't tried running this with GCJ yet, so I don't know if it's  
slower or not). Looking up an address in one of these entries seems  
really fast, such that it looks immediate to my eyes. I think the  
reason the cache is that size is related to how libgcj is compiled,  
so maybe there's one compilation unit per package. It looks really  
low-overhead to me, and is probably sufficiently fast. Each cache  
entry is just a list of file names, some info about that unit's  
header, and a ByteBuffer that is a view on the MappedByteBuffer of  
the .debug_line section.

The code is here:

   <http://metastatic.org/source/debug_line.tar.gz>

This includes a little class `dwarf2.addr2line' that simulates  
`addr2line'. It's a little hacky, since it glues the scan into the  
lookup code, but it may at least show that the approach is  
worthwhile. I'm not sure how correct the caching is, but it seems to  
look up java methods properly.
-------------- 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/20060512/65d58bbc/attachment.sig>