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> I think assuming they cannot change them is the best solution since it
Kyle> doesn't waste any memory.

Ok.  One more problem I failed to notice earlier :(

Kyle> +int _Jv_ClassReader::pool_Utf8_to_char_arr (int index, char** entry)
[...]
Kyle> +  *entry = reinterpret_cast<char *> (_Jv_AllocBytes (len + 1));

We are allocating GC memory here.

Kyle> +      _Jv_LocalVarTableEntry *table 
Kyle> +        = reinterpret_cast<_Jv_LocalVarTableEntry *>
Kyle> +            (_Jv_AllocBytes (table_len * sizeof (_Jv_LocalVarTableEntry)));
[...]
Kyle> +          len = pool_Utf8_to_char_arr (read2u (), &table[i].name);

And storing pointers to it here, into unscanned memory.

Just as a general rule, when allocating memory associated with Class
structures, you need to have a mental proof that there is a way for
the GC to trace from the Class to your allocation.

Certain fields in Class are marked (see boehm.cc if you want the gory
details).  After that the rule is that Java classes are ok (their
fields are all automatically marked by the runtime), and global
variables are ok (but we avoid those as much as possible these days).
Otherwise, you are in trouble -- malloc()d or _Jv_AllocBytes memory is
not scanned, so pointers stored there are invisible.

I think in this case you should use _Jv_AllocRawObj to allocate
'table'.  We try to avoid _Jv_AllocRawObj, but in this case it is
appropriate.

Tom


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