harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [DRLVM][Helper inlining] GC write barrier inline?
Date Wed, 06 Dec 2006 07:13:51 GMT
On the 0x236 day of Apache Harmony Rana Dasgupta wrote:
> On 11/29/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> >
> >
> >
> > >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);
> >
> > >2. In JIT, the store that incurs write barrier will not emitted. It is
> > >substituted with the inlined Java helper.
> Correct. BTW, does this break GCV4.1, or does it also generate the store in
> the helper?
> >Since I somehow am not a branch predictor fun, I am used to put the
> >common TRUE case in the branch condition so that the fast path can be
> >scheduled as fall-through branch automatically by the JIT. This might
> >be very old and obsolete C programming wisdom. :-)
> It has changed so many times across processor + compiler, that it's
> impossible for the programmer to get right :-) What does Jitrino
> expect? 

Jitrino.OPT relies on edge profile. The most probable edges are
fallthrough. I believe it is good enough not to care about branch
prediction while programming in java.

You can do similar things with GCC if you collect profile. Programmers
are often bad branch predictors.

> It is easier to just fall in with Jitrino's assumption, and then
> tune the jitrino code generation across platforms as needed.

Egor Pasko

View raw message