On 09 Jan 2007 16:47:52 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
On the 0x258 day of Apache Harmony Weldon Washburn wrote: > On 1/7/07, Robin Garner <[EMAIL PROTECTED]> wrote: > > > > 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. > > > I like it. Its concise and as far as I know, accurate. And to the more.. it *is* the current contract in DRLVM
This is good. Thanks for confirming this.
Moving to substituting write barriers exclusively is very attractive > now that vmmagic is supported in drlvm. Given that we still have > old pre-vmmagic GCs laying around, we need to support > non-substituting WBs for a little while longer. > > One thing we need to build are regression tests that demonstrate with > (hopefully) high accuracy that the JIT is correctly emitting all the WB > corner cases. The hope is that it is possible to build these regression > tests entirely in app Java. that is hardly believable. In general, number of pointer updates may vary depending on JIT optimization level (unless we mark all updated fields as 'volatile'.. and we have a free 'volatile'-related test, heh?)
hmm... I am not sure what is being said. In any case, we need some sort of rigorous WB regression test because a missing WB can cause all sorts of very hard to diagnose problems. Assuming the existing JIT code base has zero WB bugs, it is still important to have some way of discovering if future mods to the source base cause a WB regression. Ideally a non-intrusive test written in Java would be best. Of course this may simply not be feasible.
This would make these tests non-intrusive which is very desirable. > The other approach is to instrument the JVM snap all the WB writes. > The idea is to write some simple Java code, then manuallly count all > the ref ptr assignment locations. Then verify that wbCount == the > manually counted writes. Best corner cases can probably be implemented in JIT IR-level test suite (that we were discussing recently). It is currently in JIRA, but can be integrated pretty fast. wbCount verification is natural to implement with the infrastructure.
Perfect. Can the above infrastructure be extended to handle all the corner cases of WB? --
Egor Pasko
-- Weldon Washburn Intel Enterprise Solutions Software Division
