On 08/04/2008, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > Simon, good questions. > > Write barriers are used in Harmony GC mainly for two things: one is > generational GC, the other is concurrent GC. > > For generational GC, JIT should instrument ref stores (write a ref to > a field) with gc_heap_slot_write_ref invocation.
Thanks. I would like to know in which JIT phase these instruments are inserted. is it similar to the safe-point instrument? During the code > execution, it will go through the path of > WRITE_BARRIER_REM_SOURCE_REF, which checks if the reference is from > non-NOS and pointing to NOS (in other words, cross the nos_boundary), > and remembers the ref slot (the field address containing the ref) if > it is. (The remember ref slots are called remember set, in par with > root set). > > Path of WRITE_BARRIER_REM_NIL actually does nothing, except to simply > conduct the ref store. It is for the case when jitted code is > instrumented, but the GC is not generational or doesn't care about the > remember set. > > Other paths of write barrier are mainly used for concurrent GC. Yes, > they are basically used for the marking phase: the phase determining > the reachability of objects. In other words, concurrent marker thread > marks the live object from root set. Since marker thread's marking and > mutator's mutating are racing for object access, write barrier is used > to ensure the marking process correctness, i.e., no miss of any live > objects. So the write barriers are only used in mark phase? Now, I am planning to implement a fix-up phase for concurrent copying, Does it mean more barriers should be added for this case? or any other more efficient solutions? Harmony GC has implemented three different concurrent marking > algorithms: most concurrent, DLG on-the-fly, and sliding-view based > on-the-fly. They use different barriers. If you are interested in the > details, please access my blog entries on concurrent GC topics. (Might > not be very useful for your GSoC project proposal). > > Thanks, > xiaofeng > > > On Tue, Apr 8, 2008 at 7:32 PM, Simon Chow <[EMAIL PROTECTED]> > wrote: > > Hi all, > > > > I find there are 6 kinds of write barriers function: > > WRITE_BARRIER_REM_NIL = 0x00, > > WRITE_BARRIER_REM_SOURCE_OBJ = 0x01, > > WRITE_BARRIER_REM_SOURCE_REF = 0x02, > > WRITE_BARRIER_REM_OLD_VAR = 0x03, > > WRITE_BARRIER_REM_NEW_VAR = 0x04, > > WRITE_BARRIER_REM_OBJ_SNAPSHOT = 0x05 > > each of them represents a write barrier remember function in > > gc_for_barriers.cpp. > > And function 'gc_heap_slot_write_ref' is responsible for dispatching > the > > different write barriers to corresponding handler. > > > > But it seems that only WRITE_BARRIER_REM_NIL is called when running a > simple > > HelloWorld program. > > What does 'NIL' stand for? and I want to know what situation calls for > use > > of other functions. > > > > Additionally, IMO gc_gen only use write barriers for concurrently > collecting > > to incremental reachability analysis, is that true? > > > > Thanks > > > > -- > > From : [EMAIL PROTECTED] School of Fudan University > > > > > > > -- > http://xiao-feng.blogspot.com > -- >From : [EMAIL PROTECTED] School of Fudan University
