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:
 > Andrew Haley wrote:
 > >  > 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.
 > 
 > OK, it probably makes sense to use some hash structure to store the 
 > closure data - in the event that we have a whole bunch of classes all 
 > referencing the same missing class/method, then we can share just one 
 > closure for each missing method. However, it seems to me that a 
 > WeakHashMap won't do any good without custom marking code for class 
 > anyway - else there is no way for the GC to determine when an entry in 
 > the map becomes unreachable.

An entry in the WeakHashMap becomes unreachable when the class that
will use it becomes unreachable, surely.  So, the key is the class.
But it really doesn't matter ATM -- all we must have is some heap
allocated memory that won't mysteriously disappear.

 > > 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.
 > 
 > Certainly. My immediate concern here is that the code is doing some 
 > odd/wrong things with types: Allocating a jbytearray on the stack, 
 > casting it to an FFI type (thus overwriting the class pointer etc), and 
 > storing it in a Java collection.

Yes, I agree.  Well spotted.

 > IMO, this part, at least, needs to be cleaned up in some way -
 > either switching to RawData or using JvNewArray() and elements().
 > 
 > FFIBucket could then be a simple HashMap with the String passed to 
 > ffi_prep_closure as the key and the FFI closure as the data.

Andrew.


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