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: [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


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