Hi Alex,
Comment inline below.
On 6/27/06, Alex Astapchuk <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
