This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Line number support for interpreter
- From: Tom Tromey <tromey at redhat dot com>
- To: Mark Wielaard <mark at klomp dot org>
- Cc: java-patches at gcc dot gnu dot org
- Date: 10 May 2004 10:10:11 -0600
- Subject: Re: Line number support for interpreter
- References: <1084147210.1287.29.camel@elsschot.wildebeest.org>
- Reply-to: tromey at redhat dot com
>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:
Mark> Here is a first attempt at a patch to add support for line number and
Mark> source file name support to interpreted classes/methods.
Excellent!
Mark> - For the interpreter the _Jv_MethodChain now has a new pc field that
Mark> holds the current 'pc' (this replaces the, also stack allocated, pc
Mark> field in the run() method).
Hmm... I would expect that it is important for performance for `pc' to
be a local variable, so that it can end up in a register. Could you
try to measure this?
An alternate approach here would be to only set frame_desc.pc when it
is possible for the instruction to throw. In fact, ISTR having code
for this at one point (I don't remember if it is just some approach I
tried that didn't work out, or what). There aren't many instructions
that can throw, so this isn't all that hard to do.
Mark> - This new field is used by StackTrace to fill in the _Jv_frame_info.
Mark> - _Jv_frame_info.addr now either holds the actual address or the
Mark> _Jv_InterpMethod pointer depending on whether _Jv_frame_info.interp is
Mark> NULL or not. If it is not NULL then it contains the actual pc_t for
Mark> the frame.
Let's use a real union to make things less confusing.
Mark> + = (_Jv_LineTableEntry *) _Jv_Malloc (table_len
Mark> + * sizeof (_Jv_LineTableEntry));
Hmm, don't we leak this memory if the class is GCd?
Otherwise this is looking pretty good.
Tom