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. > I remember kaffe had a kaffe.util.Pointer reference type that did > this, and was specially recognized by the GC. Slightly better than > Object imho. Yes, but you have to be very careful that such instances never leak into application code. Andrew. _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
