Re: Classpath build process and VM-specific issues

[Andrew Haley]

Etienne Gagnon writes:
 > 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 didn't know that.  Is that requirement documented anywhere?  I can't
see how you'd do it on a machine with 32-bit and 64-bit modes, for
example.  Do we know that every JVM will use the same calling
convention for CNI?

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

Well, the proposals for this and opaque types aren't really
equivalent, in that I make no performance claims for using an opaque
wrapper for a native pointer.  I do claim a maintenace and
understandability advantage, however.  

Clearly the highest performance comes from using a naked long.  But
both long and byte array have the disadvantage in that they're
untyped.  The lack of typedef in Java is lamentable, but in its
absence we just have to do the best we can.

 > /* test function (unused).  This function will cause a compiler
 >  * warning when jbyte != signed char */

Maybe, maybe not.  Is this guaranteed by the standard to cause a
warning?

 > /* Assuming that jbyte != signed char */
 > 
 > #define PTRDIFF_BIT (sizeof(ptrdiff_t) * CHAR_BIT)
 > #define BARRAY_SIZE ((PTRDIFF_BIT + 7) / 8)
 > 
 > /* ----------------------------------------------------------------
 >    wrap: wraps a pointer into a jbyteArray in order to store in into a
 >    Java object instance.
 >    ---------------------------------------------------------------- */
 > 
 > inline static jbyteArray
 > wrap (JNIEnv *env, void *ptr)
 > {
 >   jbyteArray nativePtr;
 >   jbyte bytes[BARRAY_SIZE];
 > 
 >   /* make a robust integer out of pointer value */
 >   ptrdiff_t value = (char *) ptr - (char *) 0;

Don't do this subtraction, it isn't portable.  Use intptr_t instead.

 >   size_t i;
 > 
 >   for (i = 0; i < BARRAY_SIZE; i++)
 >     {
 >       bytes[i] = (value & 0x0ff);

I don't think the & 0x0ff is needed, but that probably doesn't matter.

And a little stylistic nit: it isn't a good idea to cat return values
from malloc().

Andrew.