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: Patch: Linker + Verifier fixes


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.


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