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, 07 Dec 2006 08:43:50 GMT
On 12/7/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> Xiao-Feng Li wrote:
> > On 12/7/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> >> Xiao-Feng Li wrote:
> >>
> >> >> 2)  I have to use 3 params for fast path helper because slow helper
> >> >> (gc_heap_slot_write_ref) requires 3 params.
> >> >
> >> > Mikhail, we need a simpler helper. The current helper is used for a
> >> > full barrier including both the fast-path and slow-path. It's
> >> > undesirable.
> >>
> >> Excuse me if I'm missing some details here, but surely the number of
> >> parameters to the write barrier helper is unimportant (well, within
> >> limits) ?  Since the helper (by definition) is inlined, there is no real
> >> parameter passing going on, and unused parameters will simply be
> >> optimized away.
> >
> > Robin, thanks. Yes, for the Java helper, it doesn't matter to have
> > more parameters.
> >
> > But the parameters here are those for the native function invocation
> > that does the real remembering. It is not inlined, so the parameter
> > count might have impact on performance, but we don't know without real
> > experiment.
>
> But by definition, the slow-path helper is slow.  I would be very
> surprised if extra parameters had any significant impact on speed,
> particularly with the simple boundary-crossing barrier.
>
> >
> > The other reason for a new native write barrier interface is, the
> > original one is called by VM even with non-generational GC. It's
> > undesirable to have a check in the native function body about whether
> > it's generational GC or not. We can change either the VM body or only
> > the GC side. So my suggestion is to change the GC side.
>
> Again, I would have thought this was by far the least common case - the
> mutator modifies pointers far more than the VM.
>
> I would think that rather than implement the whole thing and measure, if
> you added some simple counters of:
> - fast path invocation
> - slow path invocation
> - VM invocation

Robin, I guess we have some miscommunication.

The problem here is not about Java helper parameters. This native VM
helper function is not a real write barrier. It is only a function to
do the real remembering. It doesn't make sense for it to take some
useless parameters. This function can be invoked by other write
barrier functions (native or Java). For example,
gc_heap_slot_write_ref can call it when the GC is generational.

We are not talking about a generic write barrier API, because this
function is not a write barrier itself. I know the ratio of slow path
is much lower than the fast path, but that's not the reason to put
something useless in the VM helper.

If we want other Java write barrier functionality that the current
design doesn't support, we can modify the Java helper code later on.
But that's another thing, different from the VM native helper.

Finally, the Java helper code is specific to the GC implementation,
hence put into the specific GC directory. It doesn't impact other GC
to have other Java helper code. Now what Mikhail is building is an
inlining infrastructure that will easily adapt to different helpers.

Thanks,
xiaofeng

> that the relative numbers would give enough information to inform the
> decision.
>
> > Thanks,
> > xiaofeng
>
> cheers,
> robin
>
> >> And given that the fast-path, by definition is fast, then surely calling
> >>   it when you know that the slow-path will be taken is virtually zero
> >> overhead ?
> >>
> >> I was also under the impression that Moxie required the inlined helpers,
> >> and since Moxie uses MMTk, won't it need the additional parameters ?
> >>
> >>  >            And the API gc_heap_slot_write_ref() is called sometimes
> >> > by VM even for a non-generational GC. So its implementation is not
> >> > efficient. I'd suggest to have a simpler helper for slow-path-only:
> >> > gc_slot_remember( Managed_Object_Handle *p_slot,
> >> > Managed_Object_Handle p_target ). It is not a barrier, but only
> >> > remember the slot. For GCv5, the concrete code should look like:
> >>  >
> >> > void gc_slot_rem( Managed_Object_Handle *p_slot,
> >> > Managed_Object_Handle p_target )
> >> > {
> >> >  Mutator *mutator = (Mutator *)gc_get_tls();
> >> >  mutator_remset_add_entry(mutator, (Partial_Reveal_Object**)p_slot);
> >> > }
> >> >
> >> > How do you think? Thanks.
> >> >
> >> > This slow path needs actually only one parameter, but initially it's
> >> > ok to give two for assertion check to make sure it should be
> >> > remembered.
> >> >
> >> > Thanks,
> >> > xiaofeng
> >> >
> >> >> On 12/6/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> >> >> >
> >> >> > On 12/6/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> >> >> > > Today helpers are inlined only by SD2_OPT JIT. We can add
helpers
> >> >> > inlining
> >> >> > > to SD1_OPT too, but helpers classes are initialized only
from
> >> VMStart
> >> >> > class
> >> >> > > - so there will be ~1k methods compiled by SD1_OPT without
helpers
> >> >> > inlined
> >> >> > > and we will have a problem to differentiate them.
> >> >> >
> >> >> > Probably we can introduce some annotations to guide the compiler
for
> >> >> > branch scheduling (and probably for some other scenarios as well,
> >> such
> >> >> > as dead object for GC).  Of course that will not be prioritized
> >> until
> >> >> > some evidence shows the importance.
> >> >> >
> >> >> > Thanks,
> >> >> > xiaofeng
> >> >> >
> >> >> > > On 06 Dec 2006 16:52:12 +0600, Egor Pasko <egor.pasko@gmail.com>
> >> >> wrote:
> >> >> > > >
> >> >> > > > On the 0x237 day of Apache Harmony Mikhail Fursov wrote:
> >> >> > > > > On 06 Dec 2006 13:13:51 +0600, Egor Pasko
> >> <egor.pasko@gmail.com>
> >> >> > wrote:
> >> >> > > > > >
> >> >> > > > > > Jitrino.OPT relies on edge profile. The most
probable
> >> edges are
> >> >> > > > > > fallthrough.
> >> >> > > > >
> >> >> > > > > The only problem  here is that vmhelpers are never
recompiled
> >> >> > and  their
> >> >> > > > IR
> >> >> > > > > is estimated with heuristic based profiler. So,
as JIT
> >> developer,
> >> >> > I'm
> >> >> > > > not
> >> >> > > > > sure if a branch in Java code will be layouted
as fallthrough
> >> >> or as
> >> >> > > > jump.
> >> >> > > >
> >> >> > > > That's interesting! I see no serious reasons that can
stop us
> >> from
> >> >> > > > profiling VM helpers. Just need the right .emconf. Or
am I
> >> missing
> >> >> > > > something?
> >> >> > > >
> >> >> > > > --
> >> >> > > > Egor Pasko
> >> >> > > >
> >> >> > > >
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > Mikhail Fursov
> >> >> > >
> >> >> > >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Mikhail Fursov
> >> >>
> >> >>
> >>
> >>
> >> --
> >> Robin Garner
> >> Dept. of Computer Science
> >> Australian National University
> >> http://cs.anu.edu.au/people/Robin.Garner/
> >>
>
>
> --
> Robin Garner
> Dept. of Computer Science
> Australian National University
> http://cs.anu.edu.au/people/Robin.Garner/
>

Mime
View raw message