Hi Simone,
Simone Giannecchini a écrit :
I've tried GetPrimitiveArrayCritical() / ReleasePrimitiveArrayCritical() and
I've observed they return non-copy pointers, which make them good candidates.
Looking at
http://java.sun.com/j2se/1.3/docs/guide/jni/jni-12.html#GetPrimitiveArrayCritical,
it appears that there are restrictions to use them. But this is probably OK as
we don't callback Java code in the RasterIO operations. But I'm not sure if the
native operation can be considered to be fast enough to use those primitives. It
depends on the query size and the driver. Perhaps it is not worth the risk and
that the copy made by the JVM when calling GetByteArrayElements() is not that
significant for modest size arrays.
I decide not to take the risk. The problem with that call is that It
should block the GarbageCollector and this is highly counterproductive
in server side application (you tend to prefer less pause times more
often than a long pause time once ia while).
I didn't use it finally. Just regular
Get(Byte|Short|Int|Float|Double)ArrayElements functions.
Another possibility is that in the ReadRaster() case, we don't care about the
initial values of the array. We just want to update it in fact, so we could
allocate a working buffer in the JNI code, call the native RasterIO() on it and
upload its content into the Java array with SetByteArrayRegion(). This would
save one copy.
For the reasons I said in my previous email I would refrain from
allocating raster data inside the native code, the JVM seems to not
like that too much.
Moreover, the Java flag to control the native memory space is prefixed
XX which means that it might stop orking with no notice in a newer
java release.
I guess that the best thing, IMHO, is to stick with pinning and hope
for the best, however, it might be interesting to do kind of a testing
session having the geoserver hitting the gdal code for something like
ECW and see what happens with the different options in term of
stability/performance/robustness, what do you think?
I did use the temporary allocation of a buffer before calling RasterIO()
and then updating the Java array with
SetByteArrayRegion(). I'm not sure why the JVM wouldn't like that. It
doesn't have to deal with memory
allocations done by third-party code and I'm working daily with a Java
app that uses native DLLs that allocates
big amount of memory without any problems. If a JVM doesn't like that, I
would consider it to be seriously broken
(that would imply that GDAL can't do its own memory allocations either
and it must allocate temporary buffers for its
block cache for example...). However if you observe that it is a
problem, you could try changing the typemaps to use
the regular array pinning (it's the /* %typemap(in, numinputs=1) (ctype
*regularArrayOut, long nRegularArraySizeOut) */
around line 1400 in swig/include/java/typemaps_java.i) to see if it
changes things.
I'd be happy to hear about the results of your tests with Geoserver.
Even
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
