while I think that your proposal would work with our VM it would also be quite ineficient. Our arrays can be fragemented so we nee to do some magic when accessing them in native code.
Do you have any system that requires a pointer size larger than 64bits ?
My feeling is that once we hit systems of that size Java is in trouble for having "only" 63bits for file size and 31 bits array indces.
ingo
Etienne Gagnon wrote:
Andrew Haley wrote:
Maybe, but that's not the only thing. It's possible to define jbyte so that it is an 8 bit signed value but not a character type, and JNI does not forbid this. I suspect that all the platforms we use define jbyte to be a character type, but I can see no overpowering reason to introduce a dependency on that.
"jbyte" must have a single platform-specific definition, as all JVMs on that
platform should be able to execute the same JNI library code (no recompilation
required). I would argue that if a char type has 8 bits on a platform, there
is a strong case for it to be defined as "typedef signed char jbyte", and I would
gues VM implementors would be veery unhappy if Sum (or any other) decided to
define jbyte otherwise on that platform.
BUT.... I agree, it could be false on some system. So, assuming the worst-case
scenario, I have attached an updated version of my byte array proposal that
is, as far as I can tell, robust across all possible platforms.
It contains 2 utility "inline" functions: wrap and unwrap. I provide 2 versions
of each, one version for systems where jbyte == signed char, and one version
for systems where jbyte != signed char. A test function, ideal for use in
an autoconf macro, is provided that issues a warning when jbyte != signed char.
So, Andrew, does this version pass the portability test?
I would really like to see the native counterpart of your opaque types and compare the "theoretical" performance of it relative to the byte array proposal.
Etienne
-- Ingo Prötel [EMAIL PROTECTED] aicas GmbH http://www.aicas.com Haid-und-Neu-Str. 18 phone +49 721 663 968-32 76131 Karlsruhe fax +49 721 663 968-93 Germany
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
