I would like the vmdata field type then to be VMClass not Object.
IIRC you are the only one to voice this request. I would like it to be of type Object and I think Jikes RVM as well.
For what it's worth, in JC all vmData fields are type byte[]. This also seems the most generic and therefore (?) appropriate for Classpath (in cases where vmData isn't pointing to a "shadow" object).
However, in general I don't hold out much hope for ever being able to use Classpath unmodified, because the Foo/VMFoo split makes things too ineffiencent (although earlier I was a strong supporter of it) and moreover most VMs have already wired down their particular mechanims and ways of doing things. Also, every VM has its own priorities of maintenance ease vs. efficiency.
As an example, some VMs would perfer to use Object instead of byte[] simply to avoid the extra time & space overhead of pulling the pointer out of the byte array. Others will prefer byte[] (or whatever Classpath chooses) because it means they can merge in new Classpath versions more easily and reduce their diffs. There's no "right" answer.
I.e., I think there is an inherent conflict in trying to make the API generic enough for most/all VMs. If we were starting from scratch, it seems to me that it would make more sense to define a more efficient, less cleanly separated API. This is not really a practical suggestion now because things are already established.
Just some thoughts.. taking cover now :-)
-Archie
__________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
