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 <[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. > > 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]
