On 11/29/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Robin,
On 11/30/06, Robin Garner <[EMAIL PROTECTED]> wrote:
> Mikhail Fursov wrote:
> > Xiao-Feng,
> >
> > On 11/29/06, Xiao-Feng Li <[EMAIL PROTECTED]> 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
