I think you dind't quite get how it works with MMtk. There are a few
"magic" classes that receive special treatment from the compiler and
translates method calls into pointer operations. This way MMtk can operate
under the same condition of C code.
I'm not sure how did you relate interface calls with MMtk, as this is a
non-issue. And with memory barriers, it's a problem all languages will have
to face, be it Java, C or assembly.
But it might still be that C-implemented modules (particularly the
> GC) are faster than their Java-implemented counterparts, because
> they ignore array-index-checking, don't need write barriers and
> interface calls, etc... One could follow the strategy, that
> modules must support Java interfaces but might be implemented in
> C. This strategy would bring us back to an design that doesn't
> mandate which language has to be used to implement a certain
> module.
>
> Uli
>
