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][jitrino]Are there any static type checking and type propagation?
Date Mon, 02 Jul 2007 12:15:37 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message