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 was suggesting an template-based approach to solve the issue, but it was rejected as it was not "pure Java". "Object vmData" IS pure Java, and it also conforms to Java's view of generecity (e.g. all Collection containers store and retrieve generic "Object"s).
Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
