Am Montag, 29. März 2004 17:12 schrieb Andrew Haley: > Archie Cobbs writes: > > Andrew Haley wrote: > > > > > > I would like the vmdata field type then to be VMClass not > > > > > > Object. > > > > > > > > > > I disagree, as it imposes a restriction on what vmData > > > > > actually is. The most obvious implementation of vmData is > > > > > to be a byte[] instance holding the byte of a native > > > > > pointer to an internal VM non-moveable data structure. > > > > > > > > I'm glad to see we agree (although I don't think it's at all > > > > obvious that it should be a byte[], not all VMs use native > > > > code). > > > > > > Eeeh. I can't imagine that either. If there's a strong > > > argument for holding native pointer in a byte[] ? > > > > Here's my thinking on this topic. Warning: may not apply to you > > :-) > > > > 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). Michael _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
