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]

Re: Line number support for interpreter


>>>>> "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


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