harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [drlvm/mmtk] jitrino.jet write barrier design questions
Date Tue, 27 Jun 2006 16:21:31 GMT
Alex,

The patch in HARMONY-504 works fine for C-based GC, it can have some
problems in Java-based GC. I'm also interested in WB4C support in jet
for experimenting. Currently, I use
http://issues.apache.org/jira/browse/HARMONY-581 to get that support.

--
thanks,
Ivan

On 6/27/06, Alex Astapchuk <alex.astapchuk@gmail.com> wrote:
> Weldon,
>
> Weldon Washburn wrote:
> > It would be really nice if jitrino.jet allowed the write barrier to be
> > selected at the start of jitting an individual method.   Is this
> > possible?
> Sure. Currently, jitrino.jet handles some of OpenMethodExecutionParams
> flags to instrument the jitted code.
>
> >
> > The selections would be mutually exclusive:
> > 1)
> > no write barrier (for the existing GCV4)
> > 2)
> > write barrier written in Java (for MMTk)
> > 3)
> > write barrier written in C  (for the yet to be determined basic
> > generational GC)
>
> VM (or ExectionManager) can signal which barrier to implement using
> the flags passed to JIT_compile_method.
> The current set of seems incomplete - for instance, it does not cover
> array manipulations. Also, we can't signal the difference you mention -
> WB4J or WB4C, but sure we can extend the set.
>
> I have a look at the submitted patch for DRLVM (GC write barrier update
> patch for DRLVM - http://issues.apache.org/jira/browse/HARMONY-504), but
> seems it's only for interpreter.
>
> If no one complains, I would like to implement the WB4J we are
> discussing here in .jet.
>
> As we currently don't have C-based GC with WB support (do we?),
> for the first iteration I'm going to instrument code with WB4J in
> response to OpenMethodExecutionParams:: exe_insert_write_barriers.
> We can change this later then.
>
> Though I'm not familiar with MMTk, could please give me some clues ?
>
> AFAIR from the recent thread, to implement WB for MMTk support, I have
> to emit calls of
>
>         org.mmtk.plan.PlanLocal.writeBarrier(
>                 ObjectReference src,
>                 Address slot, ObjectReference tgt,
>                 Offset metaDataA, int metaDataB, int mode)
> on every PUTSTATIC/PUTFIELD/AASTORE.
>
> I can guess what 'src' is - this is the object being written, right ?
> But could you please point me what all other args are ?
> Can't we go without all the stuff and have only 2 args - an
> object being written and the destination class/array/instance ? :-)
>
>
> --
> Thanks,
>    Alex
>
>
>
> >
> > Allowing the "java" write barrier to be selected on a method by method
> > basis would be very useful for MMTk bring up.  The concept is to
> > initially run MMTK sort of like a "user mode linux".  That is, startup
> > the JVM w/o barriers turned on.  Run "hello world".  Then switch on
> > MMTK collector/allocator and Java write barriers and compile/run the
> > following method:
> >
> > public class InitialMMTkBringup {
> >
> >    public int stressTheMMTkAllocator ()  {
> >       while(true) {
> >         Object obj = new Object();
> >         Object [] ia = new Object[100];
> >         //at a later stage, add code that causes a write barrier
> >         //at a later stage, add code that will randomly chain Object
> > arrays together...
> >      }
> > }
> >
> > The above would be running while the underlying JVM GC is running.  If
> > not careful this could cause lots of confusion.  The intention is to
> > run MMTk in "user mode" only to the point where MMTk alloc,
> > collection, write barrier code paths are exercised.  Provided we do
> > not do anything to cause the underlying JVM GC to kick in, we should
> > be OK.
> >
> > As a second step actually integrate MMTk into the JVM.  Note that
> > basic garden variety Java debugger should work w/o modification with a
> > "user mode MMTk".

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


Mime
View raw message