[RFA/JVMTI] Implement GetLocalVariableTable and GetMaxLocals

Kyle Galloway kgallowa@redhat.com
Thu Feb 8 14:57:00 GMT 2007


Tom Tromey wrote:
>>>>>> "Kyle" == Kyle Galloway <kgallowa@redhat.com> writes:
>>>>>>             
>
> Kyle> This patch implements the JVMTI method GetLocalVariableTable.  This
> Kyle> grabs the local variable table attribute out of a class file when it
> Kyle> is loaded, similar to how a line table is obtained.  When a JVMTI
> Kyle> request for this information is given, it loads the information into a
> Kyle> JVMTI appropriate structure, or reports the data is absent if the
> Kyle> class file contained no table for this method.
>
> Kyle> Comments?
>
> This is pretty much ok.
[snip]

> Kyle> +  int get_local_var_table (char **name, char **sig, char **generic_sig,
> Kyle> +                           long *startloc, jint *length, jint *slot,
> Kyle> +                           int table_slot)
> Kyle> +        *name = reinterpret_cast<char *> 
> Kyle> +          (_Jv_AllocBytes (strlen (local_var_table[table_slot].name) + 1));
>
> I don't see how memory allocated here can ever be freed.
>
> But ... maybe we don't need to make copies of the names and such?
> I don't know whether user code might mess with the data here.
>   
Not sure exactly what you mean here.  I thought that memory allocated 
with _Jv_AllocBytes is garbage collected.  So when the caller of this 
finishes (which will almost always be _Jv_JVMTI_GetLocalVariableTable) 
and its variables go out of scope this memory can be collected.  But I'm 
no GC expert so I may be way off the mark. I can try it without the 
copy, but I think I remember that causing me problems before.
> Kyle>  static jvmtiError JNICALL
> Kyle> +_Jv_JVMTI_GetLocalVariableTable (MAYBE_UNUSED jvmtiEnv *env, jmethodID method,
>
> Remove the MAYBE_UNUSED here.  This occurs in a couple places in the
> patch.
>
> Do we need to verify that the info in the variable table is valid?
> For instance whether the PC values or variable table indices are valid?
>   
The only thing that may cause a problem is if the slot values are 
invalid indicies into the variable array for that method, this is fairly 
easy to check for so i you think it's worthwhile I can add this.  
Invalid PC values don't really matter, in my thinking, since it will 
just result in garbage values begin in the slots when the debugger reads 
them.

- Kyle



More information about the Java-patches mailing list