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] interface call devirtualization
Date Fri, 28 Jul 2006 14:55:43 GMT
I tried to fix devirtualizer to process interfaces. Still can't run such a
big application like Eclipse but initial test in JIRA 957 works.
The performance benefit of interface devirtualization for this test is
rather small (14%) but the problem now not with devirtualizer but with loop
optimizations that do not move vtable loading operation out of the loop.
Here is a small report of what was done, how to use the patch and some notes
on current DRLVM problems

What was done:
1) Devirtualization of interface calls
2) Profile directed devirtualization for both interface and class calls
3) Two new options added that work only if there are an entry-backedge
profile for a method and devirtualizer is ON.
The first option is "opt::devirt::skip_interfaces" and if set to 'false'
devirtualizer processes interfaces and selects a direct call target by
method hotness profile.
The second option is "opt::devirt::profile_selection" - if set to 'true' the
devirtualizer selects direct calls target by hotness profile for normal
methods (not interfaces)

Files in attachment (I going to add it to JIRA in a minute)
1) patch.diff - the diff with changes
+ diff includes the previous changes posted by me to this thread that count
the percent of virtual methods ... (see previous post or just skip it, this
is not so important now)
2) em configuration file and run script for Windows: use these files to run
the test. But fix paths in files first.
3) Initial test from Egor with decreased number of iterations: wait 30
seconds for each measurements is too much  :)

1) VM CHA analysys (method iteration) does not work if root class is
2) RI works fast even for the first run: OSR ?
3) The slow version of method (generated by JET) is executed one extra time
after method is recompiled, I hope we will fix it one day.
4) We really need to improve our loop optimizations.
5) It's still unclear if method hotness profile is useful for direct target
selection in devirtualizer..

Thats all for today. Please try/check the diff and comment (JIRA 957)

On 7/24/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> On 24 Jul 2006 12:17:18 +0700, Egor Pasko < egor.pasko@gmail.com> wrote:
> > Interesting results! QuickQuestions:
> > * did you include interface calls in your investigations. Or is it
> >   just invokevirtual that you tried?
> I have no idea what was the way of calling a method. The result shows only
> the percentage of actual calls of virtual methods on the top of class
> hierarchy / number of total virtual calls.
> * Why do you count number of methods with mult-dispatches? I would
> >   count only interface calls having multiple dispatches.
> I checked only methods with multiple virtual versions, because this is the
> only case devirtualizer have a choice. If method is virtual but has only one
> version (method is not overridden) it's impossible to make a mistake in
> devirtualization :)
> > For me it is interesting if
> > the patch handles the situations when classes are loaded from time to
> > time. We need to check each interface call for having multiple
> > dispatches (at runtime).
> But if we have a recompilation we can be sure that all of "hot" classes
> and methods are already loaded.
> I created HARMONY-957 for the issue and attached my benchmark. You can
> > put your patch there, please.
> My patch is a hack in entry-backedge profiler code. So I will put it with
> comments like 'this is just an example, not to be included to harmony code'
> OK, see you soon :)
> Hope I finish it till the end of the week. Any help from other people
> interested in harmony development is welcome :)
> + I'm going to ask Pavel Pervov who wants to refactor Class.h code to add
> more methods to simplify CHA analysis. The way I look for the virtual copy
> of method in superclass in my patch is really ugly.
> --
> Mikhail Fursov

Mikhail Fursov

View raw message