Re: Classpath build process and VM-specific issues

[Archie Cobbs]

David Holmes wrote:
> > - I avoid VMFoo instances (i.e, shadow objects). It seems to me that
> >   storing VM specific info in a shadow object serves no (runtime) purpose:
> >   if it can be represented in Java, store it in the original object,
> >   if it can't store it in a native C structure or whatever.
>
> But just because it can be doesn't mean it will be. Having VMFoo classes
> allows the VM to choose whether to implement in Java or natively. If you end
> up using native then sure you have one extra level of indirection. But when
> you don't use native then a native method forces an extra level of
> indirection to "un-natify" it. We have very few native methods in OVM, at
> the "application" level.

This doesn't apply to JC (albeit a special case) because "JCNI" native
methods and normal Java methods are exactly equivalent.. they're both
compiled C code.

> I prefer to see a VMFoo class with native methods, than a Foo class with
> native methods.

I'm not really arguing one way or the other, just pointing out that there
is an inherent tension between goals. Obviously the VMFoo split is better
for readability and ease of understanding, which counts for a lot.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com