The cost of stack traces

Fri May 12 21:25:00 GMT 2006

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>