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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
