This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: Linker + Verifier fixes
- From: Andrew Haley <aph at redhat dot com>
- To: Bryce McKinlay <mckinlay at redhat dot com>
- Cc: Robert Schuster <theBohemian at gmx dot net>, java-patches at gcc dot gnu dot org
- Date: Fri, 13 Jan 2006 11:26:55 +0000
- Subject: Re: Patch: Linker + Verifier fixes
- References: <43C4D798.7040906@gmx.net> <43C6B624.2040509@redhat.com>
Bryce McKinlay writes:
> Could you explain what FFIBucket is for? I can't see that this has
> any effect since the closure is allocated with _Jv_Malloc - the GC
> will neither collect nor scan malloc'ed memory.
That needs fixing -- but see below.
> I suspect the important thing is to make sure that the String for
> sym.class_name gets marked somehow, and I don't think that is
> happening with the current patch.
The string that's passed to ffi_prep_closure, you mean? OK, we need
to do mark that in some way.
> Ideally the closures should be collectable - if the class for which
> they are allocated were collected then the closures should as well,
> but since FFIBucket is static, it would prevent this even if the
> closures were allocated with JvAllocBytes(). It would probably be
> better to allocate the closures with JvAllocBytes and mark them as
> part _Jv_MarkObj when the class is being marked.
I think perhaps you missed the original dicussion. I asked for the
closure to be allocated as an array of bytes so that it could be put
into a weak hash map, rather than adding another field and special
marking code to class Class. RawDataManaged would be perhaps a better
alternative to an array of bytes.
The closures won't be gc'd at the moment because that code is TBD; the
weak hash map hasn't been created.
It's better to get this code checked in to trunk before it rots, and
then we can fix any memory management issues -- otherwise Robert is
left sitting on this huge patch.
Andrew.