harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [DRLVM][Helper inlining] GC write barrier inline?
Date Thu, 07 Dec 2006 02:07:42 GMT
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).


> 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

Robin Garner
Dept. of Computer Science
Australian National University

View raw message