harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM] adding write barriers to Jitrino.JET
Date Fri, 02 Jun 2006 04:33:58 GMT
On 6/1/06, Rana Dasgupta <rdasgupt@gmail.com> 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.


> 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.


> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message