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.
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 ?
Of course Mature->nursery pointer mutations will always be the common
case (this is after all the basis of generational GC).
cheers
On 06 Dec 2006 16:52:12 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
On the 0x237 day of Apache Harmony Mikhail Fursov wrote:
> On 06 Dec 2006 13:13:51 +0600, Egor Pasko <[EMAIL PROTECTED]> 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
--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/
