harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM][Helper inlining] GC write barrier inline?
Date Thu, 30 Nov 2006 02:44:03 GMT
On 11/29/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>
> Robin,
>
> On 11/30/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> > Mikhail Fursov wrote:
> > > Xiao-Feng,
> > >
> > > On 11/29/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > >>
> > >>     /* NOS (nursery object space) is higher in address than other
> spaces.
> > >>        The boundary currently is produced in GC initialization. It
> can
> > >> be a constant in future.*/
> > >>     public static final Address NOS_BOUNDARY = getNosBoundary();
> > >
> > >
> > > JIT inlines static final fields values as consts into the code for
> > > initialized classes today. So it's OK to initialize it on startup.
> > >
> > > The important issue we need to discuss is that JIT does not know the
> > > details
> > > of implementation of any VM helper. It only knows the semantic of it's
> > > arguments. You wrote 2 args for the helper. Is it a general case?
> >
> > Could we please have 3 arguments ?  Source object, slot and target ?  4
> > would be better (srcObj, slot, tgt and mode.
>
> I agree more arguments for the Java helper can be more flexible. I
> wrote only two for the initial version, since it is enough for us at
> the moment. If JIT proves to be effective in inlining  (i.e., constant
> propagation and folding, rse, etc. can be applied to the inlined
> sequence), more parameters can be introduced without impacting the
> performance. We can have the simple case first, assuming future
> enhancement is easy to our JIT gurus. :-)
>
>
> > And could the write barrier be substituting ?  (this is the more general
> > case - if the WB is non-substituting it's impossible to implement a GC
> > that requires a substituting barrier, but not vice-versa).
>
> Thanks, Robin. This is a very important remainder. In the example code
> I wrote, it is not substituting. Now I realize it might be a good idea
> to make it substituting.  Initially this can be achieved by:
>
> 1. Adding below as the first statement in the Java helper body:
>
>     p_slot.Store(p_target);


Given that its an inlined Java method, the simplest and cleanest approach is
to do a substituting write barrier.  My guess is that it costs nothing in
terms of performance.   It might actually be a performance win.

What I think Robin is hinting at is if its not a big deal while JIT WB
support is being worked on, please add support for MMTk WB interface.  This
will save us all the pain of reopening JIT WB support at a later date.

2. In JIT, the store that incurs write barrier will not emitted. It is
> substituted with the inlined Java helper.
>
> Thanks,
> xiaofeng
>
> > The two families of GC that come to mind are write-barrier based
> > incremental GCs, and reference counting.
> >
> > > Another issue is the date to start this work (I mean adding support
> for
> > > this
> > > helper inlining to JIT). I can start this work only next week. Is it
> OK for
> > > you?
> > >
> > >
> >
> >
> > --
> > Robin Garner
> > Dept. of Computer Science
> > Australian National University
> > http://cs.anu.edu.au/people/Robin.Garner/
> >
>



-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

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