Re: JNI memory allocation

[Andrew Haley <aph at redhat dot com>]

Simon Gornall writes:
 > 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 :-)

I see your point.  However, using long for native pointers is an
approach that is sort-of sanctified by the Real-Time Specification for
Java APIs.  This is a special-prupose set of APIs, though, and
shouldn't be thought of as part of 'pure' Java.

 > 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.

I don't quite get this.  If the SDL structure contains a pointer, I
presume that it doesn't point to a Java object.  If it does that's
fine; if it doesn't, that is not fine.

Andrew.