harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Astapchuk <alex.astapc...@gmail.com>
Subject Re: [drlvm/mmtk] jitrino.jet write barrier design questions
Date Fri, 30 Jun 2006 12:32:11 GMT
Weldon,

 >> 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 ? :-)
 >
 > Actually, the simplest form of write barrier would be one, single
 > parameter -- a ref ptr to the object getting scribbled on.  I suspect

Hmmm...
Seems I have a misunderstanding here - how comes a single ref ?

What I was thinking of, is that the WB of 2 refs is a kind of
optimization for generational GCs. I recall a thread on this
in harmony-dev - that having an object being written and the
target to write into, such GC can easily detect whether or not
the young 'src' becomes reachable from the old generation.

But what would be a 'single ref' write barrier intended for ?
Just curious...


Anyway, back to the business.
Adding 'Uninterruptible' functionality into Jitrino.JET seems
pretty easy - just avoid generating back branch pooling.
Though my understanding is that this will also require VM-side
support - in a case if 'Uninterruptible' method makes a call to
VM (allocates an object, or performs interface call or whatever).


 >before it makes sense to add MMTk write barrier to
 > jitrino.JET, we need to add intrinsics to support MMTk vmmagic
 > classes.

Seems the first to do are the org.vmmagic.unboxed.* ?

-- 
Thanks,
   Alex


Weldon Washburn wrote:
> Hi Alex,
> Comment inline below.
> 
> 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.
> 
> I think you are referring to stuct OpenMethodExecutionParams{...} in
> jit_export.h.  I took a look, it seems like the right place to put the
> switches that tell the compiler which write barrier to emit.
>>
>> >
>> > 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.
> 
> Yes, extend OpenMethodExecutionParams{...}   This seems like a good idea.
> 
>>
>> 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.
> 
> Yes and no.  The part that would be interesting to a compiler writer
> targets an interpreter thus this patch is of limited interest.
> However, the part that patches the VM is interesting to VM builders.
> A side note.  I looked at the patch for the VM code and can't help but
> comment that the mods which add gc_write_barrier() to vm_arrays() look
> to be redundant  as gc_heap_wrote_object() is already called.
>>
>> If no one complains, I would like to implement the WB4J we are
>> discussing here in .jet.
> 
> Go for it!
> 
>>
>> As we currently don't have C-based GC with WB support (do we?),
> 
> Its a long, long story.  For all intents and purposes, drlvm does not
> yet have a quality "C" GC that requires a write barrier.  I hope this
> changes soon.
> 
>> for the first iteration I'm going to instrument code with WB4J in
>> response to OpenMethodExecutionParams:: exe_insert_write_barriers.
> 
> Good idea!  Write some code and post it to JIRA.  Then I can give feedback.
> 
>> 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 agree with the above approach.  There is an MMTK api for copying a
> range of ref ptrs to the middle of a Java array object but I think we
> can ignore this api for starts.  Its probably used by internal VM when
> it does a clone of an array of references.  I iwll look into this
> later.
> 
> We need to walk through the handling of all the arguments over the
> next few emails.  Briefly, the JIT sees an ObjectReference as a
> standard, ordinary java object.  An "Address" is basically a ref ptr
> that the JIT specifically does not enumerate.  "Address" is protected
> from GC problems via the "Uninterruptible" interface.  Basically any
> method that implements the Uninterruptible interface does not sprinkle
> GC polling back branch/ret code in the emitted stream.  "Offset" is an
> integer that expresses the distance between a ref ptr and an interior
> ptr.  Both ptrs point to the same object.  There might be a hidden
> design constraint that object field layout does not change during
> execution (I have to think about this one).
> 
> Real important.  Before it makes sense to add MMTk write barrier to
> jitrino.JET, we need to add intrinsics to support MMTk vmmagic
> classes. More on intrinsics in later emails.  Before we can run
> multithread java apps on MMTk, we need to get the JIT to emit
> back-branch gc polling code.  More on this topic in a separate thread
> if you like.
> 
>>
>> 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 ? :-)
> 
> Actually, the simplest form of write barrier would be one, single
> parameter -- a ref ptr to the object getting scribbled on.  I suspect
> MMTk has such a wide, elaborate WB interface for two reasons.  First,
> MMTk is a framework for developing a wide range of GC algorithms.
> They do not want to keep going back to the interface and tweaking it
> and adding "#ifdef special_case", etc.  Second, MMTk is written in
> Java.  An optimizing JIT will inline the WB code.  Once inlined, an
> optimizing JIT will optimize away the unused parameters
>>
>>
>> -- 
>> 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
>>
>>
> 
> 




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