Subject: Re: Classpath build process and VM-specific issues - msg#00019

Previous Message by Date: (click to view message preview)

Re: Classpath build process and VM-specific issues

Hi, On Mon, 2004-03-29 at 18:42, Etienne Gagnon wrote: > Etienne Gagnon wrote: > > vmData = new byte[PTR_SIZE]; > > or > > vmData = new RawData(); > > or whatever. > > So what's the problem, with this? > > And for those who want to do: > > vmData = [internalVMpointer] > > They can deal with it in many ways, such as: > > 1- make sure [internalVMpointer] points to > a non-GC'ed memory, so that GC can identify > it as special; > 2- Set their internal compiler/interpreter to deal > specially with all accesses to vmData (and use > flow analysis to track the value propagation). > > I really think "Object" is the most "general" approach, as Classpath has > decided to have a "unique, good-for-all-vms" source base approach. I think I agree when it comes to specific VM state in the VM-interface classes since those should not even "leak" into the rest of the code at all. For general state as hold for some native JNI call (which GNU Classpath also provides for java.net, java.nio, java.io, java.util, etc) I don't think this is the right approach though. There a combination of VMClass-shadow-object with possibly a long to hold native JNI (address) state seems a better approach. There providing a VMClass-shadow-object also allows VMs that don't use out JNI/Posix/C implementation for these methods to completely override/replace these classes with their own implementation (and defines a clear interface that has to be provided). Cheers, Mark signature.asc Description: This is a digitally signed message part _______________________________________________ Classpath mailing list Classpath@xxxxxxx http://mail.gnu.org/mailman/listinfo/classpath

Next Message by Date: click to view message preview

Re: Classpath build process and VM-specific issues

Mark Wielaard writes: > > 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? It's in Eclipse 3, but it's not totally stable yet. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=37775 for all the gory details. Andrew.

Previous Message by Thread: click to view message preview

Re: Classpath build process and VM-specific issues

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 Classpath@xxxxxxx http://mail.gnu.org/mailman/listinfo/classpath

Next Message by Thread: click to view message preview

Re: Classpath build process and VM-specific issues

Michael Koch writes: > > > > To be honest I think we should not have RawData in Classpath. The trouble with RawData (as it is used in gcj) is that it breaks the Java type system. Its bizarre semantics mean that you have something that looks like an object reference but you can't use it as one. You can't convert it to an instance of Object, for example. A garbage collector can't inspect it. A VM that doesn't expect this behaviour might crash. If we use RawData like that in Classpath, a VM may need to be modified. It might not even be possible. For that reason, I believe that we should not use RawData in Classpath, although some VM implementors might choose to. I think we need a better abstraction. Perhaps a Pointer class that may be subclassed to swtPeerPointer, nativeIntPointer, and so on. That will get over the enormous and painful maintenance problem with SWT, where you have no idea what type a pointer is, because everything is implicily void*. This is truly Evil. If some VM implementers want to use a RawData reference as a raw pointer, fine. But IMO our reference JNI shouldn't. > > 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). Better. > > 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? > > The RawData pointer will get the real address to a native memory region. > It can be directly used and has always the pointer size of the > platform. Uh, I don't understand what you mean, sorry. Why is a Java reference the same size as a native pointer? Perhaps I misunderstood you. Andrew.