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


Robert,

At this stage, I would just use the native FFI types directly and remove all the casting and references to jbyteArray. The closure itself is malloc-allocated so there is no need for the GC to see it. As aph pointed out, we can revisit memory management later as needed.

The only thing that needs to be visible to the GC is the GC-allocated Java string which is being passed to ffi_prep_closure. These could just be stored in a HashMap - no need for the FFIBucket type.

Thanks

Bryce


Robert Schuster wrote:
Hi,
sorry for being mute, I was ill this weekend and could not do any computer work.

As far as I understood I should replace the current byte-Array hack with
RawData. ATM I am not sure how that has to look but I will look out for other
places where this is used and/or ask aph on IRC if I get stuck.

cya
Robert

Bryce McKinlay wrote:
Andrew Haley wrote:

 > 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.
Yes, but recall that we have a custom marking function for classes - so
to implement this would require adding code to mark the keys in the
WeakHashMap, otherwise the GC will always see them as unreachable. If we
need to add custom mark code anyway, then the need for a WeakHashMap
disappears.

But it really doesn't matter ATM -- all we must have is some heap
allocated memory that won't mysteriously disappear.
Agreed.

Bryce




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