Mark Wielaard wrote:
> With CNI a reference to gnu.gcj.RawData is used to hold data that the native
> code needs. With JNI a reference to a byte[] is used. It seems that a
> reference to RawData will not be touched by the Garbage collector. I am not
> sure why that is necessary in this case.
Yes, anything declared as RawData will not be marked or scanned by the GC (unless
there is another "real" reference to the same object, of course). This is used to
prevent data that looks like a pointer found in non-java objects from being
misinterpreted, making the collector a little more precise. This is only
necessary when the data pointed to by the RawData was allocated with malloc() or
some other non-GC allocator, since you can call _Jv_AllocBytes() to get memory
that will not be scanned for pointers. RawData can also be useful to implement
weak references and such.
> The CNI version does all Nullpointer and array bounds checking in native
> code. The JNI version does all that checking in java. I am not sure why
> you would want to do that checking in native code in this case.
> I like the JNI version more since that does all the sanity checking in
> a java wrapper and then hands of the checked data to the native code.
Its done in native code because its a bit cleaner to do it that way. If you did
the bounds check in java, you'd need to make inflate(byte[], int, int)
non-native, and then have an additional native method that gets called after the
bounds check gets done. The actual bounds checking code looks almost exactly the
same in CNI as in Java, so its just as readable to have it in the native code.
> The CNI version seems to synchronize all the native calls, the JNI version
> does not. That is how I interpret the first line of every CNI function:
> JvSynchronize sync (this);
Correct. It is often hard to say whether something should be synchronized or not
in situations where the API documentation does not specify it. In this case I
think libgcj is taking a rather conservative approach - any code trying to use
the same Inflater from different threads simultaneously sounds fairly broken to
me, so the synchronization could probably be removed for efficiency.
regards
[ bryce ]
