Andrew Haley writes: > Jakub Jelinek writes: > > On Wed, May 03, 2006 at 10:14:23AM +0100, Andrew Haley wrote: > > > Adding an entry point to register debug info should not be a big deal. > > > We're going to need it for gcj when we add a JIT. > > > > > > Another interesting possibility would be runtime extensions to > > > MD_FALLBACK_FRAME_STATE_FOR. That would be more flexible because it > > > would allow us to use a JIT's native debug info, not just DWARF. > > > > Well, MD_FALLBACK_FRAME_STATE_FOR is used solely in the DWARF2/3 > > unwinder. Furthermore, exposing the changing internals of the > > unwinder sounds like very bad idea, just registering generated > > .eh_frame with the unwinder sounds much better. > > Well, I don't know it would be better, exactly. It certainly would > fit in more closely with gcc's idea of the way the world works. > Whether that is better or worse depends on how gcc-centric your view > of the world is.
A quote from a well-known paper about JIT compiling explains why registering generated .eh_frame with the unwinder may not be the best idea: "While executing applications that use extensive security checks or exception handling, the HotSpot JVM spends a huge amount of time in stack unwinding code. The stack unwinding mechanism in IRIX HotSpot is implemented using DWARF unwind which needs to figure out the size of each frame before moving to the previous frame. The classic VM on the other hand has a better stack walking scheme as it keeps the frames as a linked list. The performance penalty for the DWARF scheme sometimes seems to dilute the better performance of the HotSpot runtime. In case of Tomcat, the HotSpot JVM spends around 19.4% of in stack unwinding code and related code." [1] This figure of about 20% is about the same for gcj. Andrew. [1] Ghulam Lashari, Suresh Srinivas, "Characterizing Java Application Performance," ipdps, p. 138a, International Parallel and Distributed Processing Symposium (IPDPS'03), 2003.
