Hi, On Mon, 2004-03-29 at 16:47, Michael Koch wrote: > Am Montag, 29. März 2004 17:12 schrieb Andrew Haley: > > Archie Cobbs writes: > [...] > > > Object is good because it is automatically the size of a pointer > > > on any platform. However, it has one significant disadvantage, > > > which is that you must special case all such fields in your > > > garbage collector (unless you have a conservative collector). > > > byte[] avoids this problem. > > > > Indeed, but so does long. I suppose it's possible that on some weird > > platform a pointer mat not fit in long. In gcj was have a class > > RawData, which we know points to something that isn't an Object and > > isn't gcable. > > Yes, gcj has gnu.gcj.RawData. > > Classpath has gnu.classpath.RawData for the same purpose. It would be > really nice to unify this. I tried once but I saw its a lot of work > needed to change gnu.gcj.RawData to gnu.classpath.RawData (or > gnu.lang.RawData or whatever).
To be honest I think we should not have RawData in Classpath. It is used in VMClass, but it seems no VM implementor actually likes how that is setup now. And it is used in some of the new nio implementation classes. But I have a hard time seeing how our reference JNI implementation will make use of it. All places where it is used have unimplemented native jni parts. How are you planning to use this? Maybe we could add state (a Object or byte[] field to the class) that holds the real data (== address). And some access method to get add the address it represents (that then might be optimized by a particular VM). But that would mean that it isn't the same type as the one from libgcj (or Ptr from kaffe) since those classes are not actually accessed through normal java code or through JNI, but handled specially through CNI or Kaffe native/vm code. As Andrew says we could maybe just use long if we want to store an address. Andrew also worked hard on getting SWT (Eclipse) 64 bit clean. What I have seen from the (huge) patch this was mainly done by turning addresses as stored by JNI from int to long. BTW, was this work ever accepted into Eclipse? Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
