On 6/1/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
Hi Weldon/Ivan,
This has been a long thread/dialog. I am going to try and summarize where
we stand at this stage ( for my own understanding ) and also to invite
comments on implementation direction and suggestions from knowledgeable VM
developers on the list. Please fill in if I miss or misstate something :-) I
have not seen the MMTk implementation.
1. The DRLVM submission has two jits jitrino.jet and jitrino.opt. The first
one is a simpler, fast baseline jit. Weldon is proposing to implement the
barrier functionality here first. The focus is initially not performance,
but to get MMTk up and running with DRLVM.
Correct.
2. For purposes of flexibility, ultimately inlinability, and since MMTk
needs it, the barrier will be a substituting write barrier. This means that
.Jet will call the barrier helper( to be defined ) and the barrier
functionality will do the store + barrier update + whatever special
functionality needed.
Correct. I will post email shortly on prelim design.
3. Read barriers are a future project, though MMTk needs it.
Correct.
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.
5. There area a few places in DRLVM code where the substituting barrier
could be a problem a) an atomic object slot update which does a test and set
followed by a conventional barrier update. This probably needs its own
interface entry and will need to be special cased. Ultimately MMTk will need
to provide some supporting functionality for this b) arraycopy and object
clone where a lot of updates happen together and then a object level barrier
is invoked. This code could just be left alone and GC suspended during the
updates for now.
Correct. In practice, it may not be as big of a deal as it looks.
6. Weldon made a late comment that MMTk needs the WB to be in Java. If true,
this is a major requirement and I did not understand the resolution if any.
Correct. In practice it may not be as bad as it sounds since MMTK by
nature already contains write barriers written in (surprise!) Java.
Thanks,
Rana
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
