Indeed. The goal is to find the optimal solution that would be spec compliant, portable and efficient. Since I obviously believe that my proposal is better than the byte[] proposal, I would like to convice Etienne (and you) of this. I fail to see how you can take issue with that.
Fair.
I don't feel like writing real JNI code, but here is the general idea:
So, you don't have a real proposal... We need to compare *real* JNI code to real JNI code, otherwise, we'll be arguing about misconceptions.
I still think that my proposal is better than the one you sketched below.
jobject WrapPointer(JNIEnv* env, void* p)
{
#if PLATFORM_HAS_32_BIT_NATIVE_POINTER
For one thing, my proposal does not need any specific #ifdef per pointer size.
jclass pclass = env->FindClass("RawData32");
jmethodID mid = env->GetMethodID(pclass, "<init>", "(I)V");
That's supposed to be faster than my proposal????
return env->NewObject(pclass, mid, p);
** Bzzzt *** Please try again...
Now that my proposal has been criticised to death on the smallest nitpicks of pure ISO C portability, let me comment on the portability ]of your code.
The ISO C standard says:
[#6] Any pointer type may be converted to an integer type;
the result is implementation-defined. If the result cannot
be represented in the integer type, the behavior is
undefined. The result need not be in the range of values of |
any integer type.So, the conversion of "p" to "jlong" or "jint" yields a *compiler-specific* value; ISO C does not guarantees anything about the actual value resulting from the cast. In other words, a compiler would be allowed to change the bits of the pointer value when converting.
Now, *my* proposal, when "jbyte == signed char", does not convert the pointer to an integer, which is something non-portable across *compilers* on a same platform. [Remember: the *main* objective of JNI is portability across VMs (and compilers) on the same platform, because you shouldn't have to recompile the library to work with another VM].
So, no, your proposal is NOT portable, and is of thus ranks lower than
my proposal on 2 counts:
1- Efficiency:
- my approach needs no call to FindClass & GetMethodID
- wrapping the pointer causes no execution of Java byte code,
but in your case, the constructor <init> must be executed.
2- Portability:
- Your code uses an implementation-defined (i.e. compiler-specific)
conversion; and cannot guarantee that the pointer will be actually
restored on unwrapping.FYI: Annex K "portability Issues" (informative) of the ISO C specification specifically points out the following as being implementation defined:
K.3.7 Arrays and pointers
[#1]
-- The result of converting a pointer to an integer or
vice versa (6.3.2.3).Your proposal fails portability on this account.
I a real implementation you'd obviously cache the jclass and jmethodID/jfieldID. I don't think this is less efficient or less portable than using a byte[].
Caching jclass/jmethodID/jfieldID will not solve all the problems; you still call the constructor <init>. Not only will this cause execution of Java code (which is not required in my proposal), but on non-optimizing JVMs, it will cause execution of 3 constructors(!!): 1- RawData32.<init> 2- RawData.<init> 3- Object.<init>
> It only requires a (tiny) bit of extra
code to support different pointer sizes.
Mine requires none.
Also, it is highly probable that we'll get to 128-bit platforms one day: just imagine if you could use a secure hash, like SHA-1 as hashcode to store data in a virtual memory implementation with 128-bit addresses! :-) I *am* serious.
There is nothing magical about it, but it does allow JITs (on VMs that don't use JNI to interact with the RawData pointers) to optimize access.
Your proposal is slower for JNI-compliant VMs, and it is not portable.
You see: this is why I wanted you to show me JNI code, as I have thought about the problem for quite a while before settling with the idea of byte arrays.
Etienne
-- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
