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 Tue, 27 Jun 2006 11:24:45 GMT

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

		ObjectReference src,
		Address slot, ObjectReference tgt,
		Offset metaDataA, int metaDataB, int mode)

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 ? :-)


> 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

View raw message