It looks like multiple interesting design topics. My comments inlined below.
On 1/6/07, Robin Garner <[EMAIL PROTECTED]> wrote:
I disagree. Partly from the point of view of eventual support for MMTk, but also on more general grounds, in terms of support for future GC algorithms. If the memory manager requires that the compiler invoke the write barrier for each pointer store, then it should honour the contract and do so.
Good point. I don't recall the contract specifically stating each write to an object slot requires a call to the write barrier. It must have fallen through the cracks. It seems we should create a clearer contract. On a related note, should DRLVM gc/vm contract say that only substituting write barriers are allowed? The reason I mention this is because if the JIT is allowed to call the write barrier as a seperate operation from doing the actual writes, then we probably have to specifiy if the write barrier has to happen before/after the actual write. A real messy one would be specifying the distance between a write and its write barrier. Is it OK for the JIT to lazily generate a WB as late as the next object write? What is the contract for volatile variables? During optimizations, can WB "x" be lazily delayed until after a later write to object "z"? I am beginning to see new value in using substituting write barriers -- it eliminates creating some very ugly and inflexible contracts between JIT, VM and GC. I understand the performance potential of optimizing out a write barrier if the app code is linearly writing many fields of a given object. I don't understand if this happens often enough in workloads we care about. At this stage of Harmony VM development, perhaps it makes sense to always match a ref write w/ a WB. Then let the workloads users care about actually drive better design if needed. Isn't arraycopy already a special case? In otherwords, it might just be that part the performance potential is already captured in the special case code for arraycopy of type reference. If you want to provide an object remembering barrier that the compiler can call as an optimization, then by all means do so, but the GC should not be forced to work around compiler 'optimizations' that break fundamental interface contracts. While object remembering barriers may be adequate for GCV5 there are a large family of GC algorithms that they are inadequate for, including reference counting and concurrent/incremental GCs. regards, Robin
Hi, I found write barrier in DRLVM can't catch all reference fields updates, and the problem is identified to be caused by new jit opts that do not observe the write barrier invariant for fields updates. For example, JIT may generate code to copy consecutive fields of an object without invoking write barrier. In order to revive the write barrier functionality while not sacrificing the opt performance,
Yes. But first how much performance is being sacrificed? .2%? 8%??
I'd suggest to introduce an object remember write barrier which will be invoked after the object is copied. So the JIT doesn't need to insert barrier for each field store.
hmm.... what happens if some other app thread causes a GC to happen in the middle of writing a bunch of fields of a given object? If the gc_heap_wrote_object() is called before JITed code scribbles on slots, then the early slots will be scanned and handled properly by the GC. But how do we handle the slots written after the GC completes? One approach would be for the JIT to mark such regions of emitted code "Uninterruptable". Another approach would be to emit a WB both before and after a region of multiple ref field scribbles. In any case, it looks like we need patch up the holes in the contract between jit and gc. However, as I said above is there anything wrong with a real simple dumb contract for now? That is each ref write has a matching WB with no intervening instructions.
GC has an interface gc_heap_wrote_object(p_obj) for this case. I think it's ok to insert only the runtime native call at first. Then later we can consider to inline the object remembering barrier as well as the slot remembering barrier. Thanks, xiaofeng
-- Weldon Washburn Intel Enterprise Solutions Software Division
