Xiao-Feng Li wrote:
On 1/8/07, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> 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.
Why can that be an issue? GC can only happen at safepoint, it can't
happen in the middle of object copy. Object copy exists no matter
there is write barrier or not.
I think this is the specification of the contract (if DRLVM persists
with non-substituting write-barriers): no GC safe point can occur
between the write of a field and write-barrier completion. Within a
basic block (or a chunk of @Uninterrubtible code) , the compiler can do
whatever instruction scheduling it likes.
Thanks,
xiaofeng
>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
--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/
