This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
[RFC] Number of insn slots used for method compilation
- From: Keith Seitz <keiths at redhat dot com>
- To: java-patches at gcc dot gnu dot org
- Date: Wed, 18 Jan 2006 14:17:03 -0800
- Subject: [RFC] Number of insn slots used for method compilation
Hi,
Before moving on with the next patch, I have a question for the gurus
out there...
As you know, when _Jv_InterpMethod compiles a method, the number of insn
slots may change relative to the number of bytecode instructions that
comprise the method, i.e., code_length is not a valid indication of how
many insn_slots are contained in _Jv_InterpMethod->prepared.
Other than adding a variable to hold this information (a la the attached
patch), is there another way that won't require using any more memory? I
don't think that code_length can safely be changed to store this
information.
[I plan to use this information to form code indices for reporting
Locations in JDWP. So when the debugger says "set a breakpoint at code
index N" in some method, it is easy for us to use
_Jv_InterpMethod->prepared[N] to get at the actual insn.]
Keith
Index: include/java-interp.h
===================================================================
--- include/java-interp.h (revision 109918)
+++ include/java-interp.h (working copy)
@@ -145,6 +145,7 @@
_Jv_LineTableEntry *line_table;
void *prepared;
+ int number_insn_slots;
unsigned char* bytecode ()
{
Index: interpret.cc
===================================================================
--- interpret.cc (revision 109918)
+++ interpret.cc (working copy)
@@ -330,6 +330,7 @@
if (! first_pass)
{
insns = (insn_slot *) _Jv_AllocBytes (sizeof (insn_slot) * next);
+ number_insn_slots = next;
next = 0;
}