This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFC: stack trace info for interpreter frames


Tom Tromey writes:
 > This patch changes libgcj so that it prints info about the interpreted
 > function when an interpreted frame is found in a stack trace.
 > 
 > It works by keeping a chain of stack-allocated objects describing the
 > interpreted frames.  Then for any frame found to be in the interpreter
 > we use this information to find the actual underlying method and print
 > it instead of `_Jv_InterpMethod::run'.
 > 
 > At this point I'm asking for opinions on a few topics.  The code isn't
 > quite ready to go in (for one thing it doesn't handle the case where
 > there is no interpreter).
 > 
 > * Should I add a parallel array for the stack trace instead of what is
 >   done now (allocating one array twice as long and then using the

The double-length array is kinda kludgey.

 > * Should the interpreter method info chain be kept somewhere other
 >   than Thread?  (I chose Thread since it is already conveniently
 >   per-thread.)

Thread is good, and surely better than some special structure.

 > * Is the technique of putting dummy functions before and after the
 >   interpreter function portable enough?  It works ok for me on my
 >   Linux box, but that's hardly definitive.  (If not this approach,
 >   then what?)

You could just look at the name of the method on the stack, but I like
the dummy functions solution well enough.

 > * Anything else anyone cares to critique.

It would be nice to have a small comment explaining the
constructor/destructor trick.  "Indicate that we're the top-most
interpreter frame." doesn't quite explain it all.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]