harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm] interface call devirtualization
Date Thu, 20 Jul 2006 02:41:37 GMT
On the 0x1AB day of Apache Harmony Mikhail Fursov wrote:
> > Seems like the best choice is to start from a couple of easy heuristics:
> > * if there is only one loaded class to implement the interface, choose it
> > * if there are more, choose the one with it's method invoked earlier
> > (compiled
> >   by some JIT, possibly, some other JIT),
> > * if we have many candidate methods that are compiled, choose the most
> > frequent
> >   one (need a method-entry profile, the feature is likely to stay
> > untouched for
> >   a while, I guess)
> >
> >
> > 1. Does anybody have some additional elegant ideas?
> >
> >
> Egor,  I'm interested in devirtualizer improvement too.


> IMO the profile based devirtualization will probably have the best results
> and is easy to implement and to check: infrastructure in Jitrino is ready to
> do it right now with a help of entry-backedge profile collected for OPT by
> JET.

OK, if it is not so difficult to use the profile. BTW, if I have a
backedge in my HIR, how do I identify it with JET's backedge? Or is
this done automatically in some way I should not care about?

> + more ideas I have:
> 1) to use edge profiler as value based one if initial compilation
> devirtualize all possible dispatches and count their edge frequencies.

Oh, that's a real code bloater!:) IMHO, inlining of these 'possible
dispatches' should be disabled. Needs to make a hint for inliner. Not
a difficult task though. Just an extra flag in call instruction.

> 2) implement a real value profiler - this is not an easy task, but may be
> reused in other optimizations

Yes, sure. This is a big item for ongoing development.

> 3) Add special annotations to classlib code about the most probable
> dispatch. E.g. if the variable type does not depend on user's environment
> and developer can prove that 90% of time the variable is of specific class -
> JIT can read this annotation from method during the compilation and to
> devirtualize it.

Okay, waiting for 1.5 support here. I like the idea of writing
annotations for devirtualization, parallelization, and other. They can
provide hints without changing program semantics. I think, they should
be available not only in classlib, but for user code too.

> I will read more about other devirtualization techniques we can use and will
> reply in a several days with results.

That would be great! Thanks for ideas!

Egor Pasko, Intel Managed Runtime Division

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message