I didn't look at the MMTk source, but IMHO the special translation of bytecodes is not nessasary in first stage. If the functionality implemented as methods which are handled specially in jikes, in interpreter they can be implemented as native methods. Anyway, I do not insist on the use of interpreter, just wanted to clarify this case.
As for the patch, you will at least find the places in VM code where missing write barriers should be added. Regards, -- Ivan 2006/6/2, Weldon Washburn <[EMAIL PROTECTED]>:
> 4. The http://issues.apache.org/jira/browse/HARMONY-504 patch has the > corresponding VM and support for WB. In this patch, the interpreter also > supports write barriers. So in theory, one should be able to bring up MMTk > in interpreter mode even before modifying .Jet? After a closer look, I can give a definite "maybe" on this one. In practice it might end up being just as much or more work as bringing up Jitrino.JET because a bunch of MMTK pointer manipulating classes must somehow be translated via javac into bytecode patterns that trigger the interpreter to bend the type safety rules and do stuff like move an int into a ref ptr field. Other approaches would be to modify javac to generate unsafe code (yuk!) We could also use some sort of automated bytecode editor to hack the bytecode stream -- maybe use sed/awk/ruby/perl/forth. The classes in question are located in org.vmmagic.unboxed (I think). Note that once you bring up the interpreter, you still have to bring up the compilers. While still to early to call, using an interpreter approach is not promising.
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
