On Tue, 2005-05-24 at 19:08 -0300, Rodrigo Kumpera wrote:
> 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.
There are some other subtleties here as well:
- MMTk takes great care to access the heap in ways that don't fire a
barrier at an inappropriate time. This would of course be a disaster
during a GC :) The magic types don't have barriers.
- There are magic array types (eg AddressArray) that don't have bounds
checks.
- In any heavily used method, MMTk optimizes for the frequent case, as
an example, the kernel of the bump-pointer allocator looks like this:
final public Address alloc(int bytes, int align, int offset)
throws InlinePragma {
Address oldCursor = alignAllocation(cursor, align, offset);
Address newCursor = oldCursor.add(bytes);
if (newCursor.GT(limit))
return allocSlow(bytes, align, offset);
cursor = newCursor;
return oldCursor;
}
This compiles down to somewhere in the region of 10 instructions, only
calling out to the slow and complicated bit(aptly named allocSlow)
whenever we cross the boundary of the current block (ie very rarely).
In performance critical code like this MMTk is very careful to avoid
null-checks, invokeInterface, array bounds checks and anything else
expensive. The result is _extremely_ fast allocation that is actually
inlined right into the user code.
Apart from the magic Address type you can see used here, note the
InlinePragma exception - this is used to force the compiler to do
inlining. The allocSlow method has a NoInlinePragma, forcing it
out-of-line, which boosts performance by not polluting the i-cache (see
Steve's "In or Out" paper).
So with some help from the JikesRVM opt compiler, MMTk doesn't suffer at
all in the performance area from being written in Java.
cheers,
Robin
