Re: Classpath build process and VM-specific issues

[Etienne Gagnon]

Jeroen Frijters wrote:
> 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/