harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "clara" <clarazh...@gmail.com>
Subject Re: [drlvm][jitrino]Are there any static type checking and type propagation?
Date Tue, 03 Jul 2007 03:26:39 GMT
Thanks.

We are exploiting an inter-procedural k-layer escape analysis, which are not dependent on
inlining. So we will do some cross-procedure type propagation ourselves. :-)
Could you give us some advices on it according to your experiences?

--clara

----- Original Message ----- 
From: "Mikhail Fursov" <mike.fursov@gmail.com>
To: <dev@harmony.apache.org>
Sent: Monday, July 02, 2007 8:15 PM
Subject: Re: [drlvm][jitrino]Are there any static type checking and type propagation?


> My 2 cents:
> 
> Clara,
> in your example the type of collection is known at compile time (Tree) so no
> devirtualization is required and 'virtual' call must be replaced with
> 'special'  (or direct) call by JIT.
> If inliner inlines 'bodies' method - the type of 'bodyTab' is also known at
> compile time and 'elements' method is also can be inlined.
> 
> Right after method inlining you can see in log that there are operations
> like 'copy o1(type MyMap), o2(type java.util.Map)'  that are used to join
> args and return values of inlinee and inliner methods. Use simplification
> pass ('simplify','uce','dce') to remove redundant copy instructions and
> propagate operand types.
> 
> Hope it helps.
> 
> On 02 Jul 2007 10:37:42 +0400, Egor Pasko <egor.pasko@gmail.com> wrote:
>>
>> On the 0x307 day of Apache Harmony Xiao-Feng Li wrote:
>> > On 7/2/07, clara <clarazhang@gmail.com> wrote:
>> > > Each operand has type info in JIT IR, and I think the type is decided
>> > > according to the declarations.
>> > > However, the runtime type of some operands can be decided in
>> compilation.
>> > > Are there any optpasses which do some type inference or analyzing?
>> > >
>> > > For example, the below are 3 classes, according to analyzing the code,
>> we
>> > > know the runtime type of e is Body$Enumerate.
>> > >
>> > > public class BH
>> > > {
>> > >     Tree root = new Tree();
>> > >     ...
>> > >     public static final void main(String args[])
>> > >    {
>> > >        for (Enumeration e = root.bodies(); e.hasMoreElements(); )
>> > >         ...
>> > >    }
>> > > }
>> > > class Tree
>> > > {
>> > >     ...
>> > >     private Body       bodyTab;
>> > >     final Enumeration bodies()
>> > >    {
>> > >       return bodyTab.elements();
>> > >    }
>> > >    ...
>> > >
>> > > }
>> > > final class Body extends Node
>> > > {
>> > >     final Enumeration elements()
>> > >    {
>> > >       // a local class that implements the enumerator
>> > >       class Enumerate implements Enumeration {
>> > >          private Body current;
>> > >          public Enumerate() { this.current = Body.this; }
>> > >          public boolean hasMoreElements() { return (current !=
>> null);  }
>> > >          public Object nextElement() {
>> > >             Object retval = current;
>> > >             current = current.next;
>> > >              return retval;
>> > >         }
>> > >       }
>> > >       return new Enumerate();
>> > >    }
>> > >
>> > > }
>> >
>> > Clara, now I understand what you meant. It is about cross-procedure
>> > type propagation. I guess this should be done with IPA. I do not know
>> > about how Jitrino deals with it. In Open64 (ORC) for speculative
>> > analysis, we used inlining to propagate the information automatically.
>>
>> Yep, Jitrino loves to inline final methods. And here it would know the
>> exact type. If there are several variants of a type on some call site,
>> then the target type can be 'predicted' using profile information and
>> then devirtualized (with a 'guard') upto the exact type. This
>> optimization is limited and per-callsite.
>>
>> So, Jitrino does not perform inter-procedural type prediction
>> optimization except one: the "Lazy Exception" optimization that allows
>> to bypass constructing exception if it is not used in catch blocks of
>> other methods. (In this case I would also prefer to aggressively
>> inline the hottest throw-catch paths with partial inlining, to make
>> code less bloated)
>>
>>
>> --
>> Egor Pasko
>>
>>
> 
> 
> -- 
> Mikhail Fursov
>
Mime
View raw message