b) The mess in java_raw_api.c is mostly caused by treating the `raw'
argument to ffi_java_raw_call as a pointer to ffi_raw, when it is really a
pointer to _Jv_word. The two unions are not compatible, or even close.
For instance ffi_raw may not have a 32-bit integer member resembling a
`jint'.
This whole file ought to be looked at more closely, since it seems to be
using ffi_raw as something it isn't. I'd expect ppc64 to have the same
problems as sparc64.
I'm out of the loop now, but it should be known that the "raw" api was
thought as an optimized version of the general ffi api which would make
sense exactly on architectures where the interpreter's stack (i.e. the
union of jint, jchar, etc.) is very similar to the layout of arguments
in the host environment's ABI. As such, it is indeed ugly; and relies
on all kinds of assumptions...