harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Chow" <simon.harm...@gmail.com>
Subject Re: [drlvm][gc_gen] write barriers in gc_gen
Date Thu, 10 Apr 2008 04:20:52 GMT
On 08/04/2008, Xiao-Feng Li <xiaofeng.li@gmail.com> 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 <simon.harmony@gmail.com>
> 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 : Simon.Chow@Software School of Fudan University
> >
>
>
>
>
> --
> http://xiao-feng.blogspot.com
>



-- 
>From : Simon.Chow@Software School of Fudan University

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message