Re: Classpath build process and VM-specific issues

[Archie Cobbs]

Jeroen Frijters wrote:
> > 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