RE: Classpath build process and VM-specific issues

[Jeroen Frijters]

Grzegorz B. Prokopski wrote:
> On (07/04/04 13:47), Jeroen Frijters wrote:
> > Andrew Haley wrote:
> > > This seems to be identical to my proposal.
> > > 
> > > I no longer understand what we're arguing about...
> > 
> > I know. I thought we were still trying to convince Etienne :-)
> 
> I thought the goal was finding the optimal solution that would be spec
> compliant, portable and efficient.

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.

> And I still haven't seen good example from Andrew about how native
> part of his "opaque class" would look like and what burden would it
have.

I don't feel like writing real JNI code, but here is the general idea:

jobject WrapPointer(JNIEnv* env, void* p)
{
#if PLATFORM_HAS_32_BIT_NATIVE_POINTER
  jclass pclass = env->FindClass("RawData32");
  jmethodID mid = env->GetMethodID(pclass, "<init>", "(I)V");
  return env->NewObject(pclass, mid, p);
#else if PLATFORM_HAS_64_BIT_NATIVE_POINTER
  jclass pclass = env->FindClass("RawData64");
  jmethodID mid = env->GetMethodID(pclass, "<init>", "(J)V");
  return env->NewObject(pclass, mid, p);
#else if PLATFORM_HAS_128_BIT_NATIVE_POINTER
  jclass pclass = env->FindClass("RawData128");
  jmethodID mid = env->GetMethodID(pclass, "<init>", "(JJ)V");
  jlong hi = HI_FROM_PTR(p);
  jlong lo = LO_FROM_PTR(p);
  return env->NewObject(pclass, mid, hi, lo);
#else
  #error unsupported
#endif
}

void* UnwrapPointer(JNIEnv* env, jobject pobj)
{
#if PLATFORM_HAS_32_BIT_NATIVE_POINTER
  jclass pclass = env->FindClass("RawData32");
  jfieldID fid = env->GetFieldID(pclass, "ptr", "I");
  return (void*)env->GetIntField(pobj, fid);
#else if PLATFORM_HAS_64_BIT_NATIVE_POINTER
  jclass pclass = env->FindClass("RawData64");
  jfieldID fid = env->GetFieldID(pclass, "ptr", "J");
  return (void*)env->GetLongField(pobj, fid);
#else if PLATFORM_HAS_128_BIT_NATIVE_POINTER
  jclass pclass = env->FindClass("RawData128");
  jfieldID fidHi = env->GetFieldID(pclass, "ptrHi", "J");
  jfieldID fidLo = env->GetFieldID(pclass, "ptrLo", "J");
  jlong hi = env->GetLongField(pobj, fidLo);
  jlong lo = env->GetLongField(pobj, fidLo);
  return PTR_FROM_HI_LO(hi, lo);
#else
  #error unsupported
#endif
}

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[]. It only requires a (tiny) bit of extra
code to support different pointer sizes.

> About the other "solution" - a comment. Why again use 
> something "magical"?
> A magica class in this case called RawData.

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.

Regards,
Jeroen