harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [DRLVM][Helper inlining] GC write barrier inline?
Date Thu, 07 Dec 2006 14:11:57 GMT
On 12/7/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> Mikhail Fursov 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.
> In the JikesRVM OPT compiler, write barriers and so on are inlined at
> the point where bytecode is translated to HIR.  This allows the compiler
> to apply the full range of intraprocedural optimizations to the barrier.

My point here is to simplify translator as much as possible and reuse
existing HLO inliner routines. This allows us to inline helpers after edge
profile is already applied. But I'm agree with you that helper inlining must
be done at the early stage, so every optimization will process helpers.

We can inline helpers before instrumentation with edge profile and annotate
helper with edge profile after method is recompiled. I think we need to
check this scenario right after helpers code become more stable. The only
proflem to check it right now is the problem with profile synchronization:
helpers are inlined only after <clinit> is executed, so part of the methods
compiled by initial SD1 JIT (first JIT in server dynamic mode) will not have
inlined helpers.

  Wouldn't this approach make the most sense here ?  Then nothing
> special needs to be done to gather edge profiles etc for barriers
because they are simply part of the given method ?

Yes, I think we need to try this approach.

Mikhail Fursov

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