harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM][Helper inlining] GC write barrier inline?
Date Thu, 30 Nov 2006 02:07:10 GMT

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:


2. In JIT, the store that incurs write barrier will not emitted. It is
substituted with the inlined Java helper.


> 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/

View raw message