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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath