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 Mon, 24 Jul 2006 13:31:16 GMT
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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message