Weldon,
I thought about slightly different approach.
Why not to write fast-path VM helper like was proposed in the thread
"[drlvm]Extending..."
This helper (a static method) can be inlined by JIT without any
devirtualization and call any method needed from MMTk or native
implementation. So JIT won't know if it works with MMTk or with a native GC:
all you need is just to replace the Java version of the helper.
?
On 10/11/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
I am just now getting back to the MMTk port.
Looking at MMTk code base, I see that during bootup MMTk creates an
org.mmtk.vm.VM object. The VM object contains a static field that holds
an
instance of Barriers. It is called org.mmtk.vm.VM.barriers.
The complete VM declaration is:
public static final Barriers barriers;
And, of course, the instance method performWriteInBarrier() can be
devirtualized by an optimizing JIT. There is no need to improve the
performance of the write barrier in JET. Thus there is no need to change
the existing MMTk interface.
I can create something like
class MMTkInitization {
static org.mmtk.vm.VM vmBoot;
void init() {
vmBoot = new org.mmtk.vm.VM();
}
The JIT would use reflection to find vmBoot field and then find
performWriteInBarrier() entry point.
Another approach would be to add a new API to JIT/VM interface that would
return the entry point performWriteInBarrier(). Its certainly not as
clean
and maintainable since its an ugly "devirtualization" hack that will break
if MMTk even wants to subclass Barriers.java
--
Weldon Washburn
Intel Middleware Products Division
--
Mikhail Fursov
