This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [RFA/JVMTI] Implement GetLocalVariableTable and GetMaxLocals
>>>>> "Kyle" == Kyle Galloway <kgallowa@redhat.com> writes:
Kyle> with _Jv_AllocBytes is garbage collected.
>>> Oops, I misread this. You are correct.
>>> Thanks.
Ok, sorry about this, but we have to revisit the allocation issue.
Kyle> And here it is. This patch now checks to see if the slot in the
Kyle> variable table is > method->max_locals (therefore trying to access
Kyle> invalid memory) or if it is < 0 (which is just plain wrong). I think
Kyle> that solves the problem.
Thanks.
Kyle> + jerr = env->Allocate (static_cast<jlong>
Kyle> + ((*num_locals) * sizeof (jvmtiLocalVariableEntry)),
Kyle> + reinterpret_cast<unsigned char **> (locals));
Here we allocate using malloc (essentially)...
Kyle> + if (imeth->get_local_var_table (&((*locals)[table_slot].name),
Kyle> + &((*locals)[table_slot].signature),
Kyle> + &((*locals)[table_slot].generic_signature),
... then we fill with pointers to GC memory.
Since malloc'd memory is not scanned by the GC, nothing is keeping
these pointers alive. So, I think they are available for immediate
collection.
Also it seems somewhat unsafe to assume that the jvmti user will be
gc-friendly.
Perhaps another approach would be to compute how much memory is needed
by all the memory in the table, then allocate a big buffer --
obstack-style.
Or if we can assume that jvmti users are not allowed to overwrite the
returned strings, then we needn't copy them at all.
Tom