Re: JNI memory allocation

[Simon Gornall <gcj at gornall dot net>]

Boehm, Hans wrote:

> My reaction:
>
> 1) I'd be inclined to either write portable JNI code or stick to CNI.
>  
I was getting 'Abort's, and thought there might have been problems with 
the memory allocation code - there was a lot of debug statements around 
all the *allocs etc. I figured that if I could use the GC for memory 
allocation, it might be more stable. In the end, it turned out that the 
Abort's were being caused by more than one thread accessing the video 
hardware - at different times, but this still caused problems...

> 2) Sticking pointers into jints is not recommended.  On 64-bit machines they don't fit.
Agreed - I had thought of replacing them all with jlong's, but that just 
defers the problem :-)

Instead, I now call JvNewByteArray, copy the returned SDL structure data 
into it, and return a jbyteArray, rather than the jint previously used. 
Any pointer areas in the SDL structure, I propogate to the appropriate 
member-variables in the Java container class. Seems much more robust.

> 3) I'm not sure what the best way is to allocate collectable untraced memory from
> CNI.  You want something like _Jv_AllocBytes, which you presumably shouldn't use.
> The collector call is GC_MALLOC_ATOMIC, which you probably shouldn't use directly
> either.  JvNewByteArray does a bunch of extra work.  Tom?
>
> 4) The collector should handle the interior pointer into the array object correctly,
> but only if the pointer is in an automatic (stack) variable.  That makes this a bit
> brittle for my taste.  _Jv_AllocBytes wouldn't have this problem.
I don't really follow what you said there...

ATB,
   Simon