harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] interface call devirtualization
Date Wed, 12 Jul 2006 23:58:26 GMT
Hi Egor,
 Nice benchmark. Yes, the cost of not devirtualizing as well as not hoisting
ldintfcvt is high. I played around a little with this too and have some
comments and questions...

  First some high level stuff....
  1) What are the instructions like ldintfcvt, ldvfnslot, etc.in the jit
dump? Are these part of jitrino HIR? While they seem more or less readable,
is there any doc describing them ... since they are the first level internal
representation, and anyone who wants to work with the jit needs to
understand them?
  2) When experimenting with the JIT related command line options to
ij.exe-Xjit...I found many of them listed in the vm/doc/GettingStarted
guide...Just FYI for interested folks.

  Please see below...

On 10 Jul 2006 22:44:52 +0700, Egor Pasko <egor.pasko@gmail.com> wrote:
>
>
> >I looked through the list of TODO projects for JIT [1] and decided to
> write a
> >microbenchmark detecting how good interface call devirtualization works
> in JIT
> >(see below)
>
> >Jitrino.OPT showed very-very slow (~2.5 times slower than JRockit (1.5
> /linux)).
>
> > A strange thing, "interface call devirtualization"
> >would have boosted JRockit's performance too (I checked that with a
> >slightly changed benchmark).


  Yes, this optimization would have helped here...I also converted this
interface dispatch effectively to a virtual dispatch in your test and the
performance significantly improves with the resultant devirtualization...


Block L8:
  Predecessors: L7
  Successors: L11 L9
  I74:L8:
  I40:ldvtable  t13 ((t27)) -) t28:vtb:cls:IntfcImpl
  I41:getvtable cls:IntfcImpl -) t29:vtb:cls:IntfcImpl
  I42:if ceq.vtb t28, t29 goto L11
  GOTO L9

Block L9:
  Predecessors: L8
  Successors: L14 UNWIND
  I37:L9:
  I43:tauhastype      t13,cls:IntfcImpl -) t30:tau
  I44:ldvfnslot [t28.IntfcImpl::inc] ((t27)) -) t31:method:inc
  I46:callimem  [t31](t13) ((t27,t30)) -)
  GOTO L14

Block L11:
  Predecessors: L8
  Successors: L12 UNWIND
  I38:L11:
  I48:--- IntfcImpl::inc: ()
  I49:chknull   t13 -) t32:tau
  GOTO L12

>So, that would be interesting to implement it!
>
> >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 forget the profile guidance for now, could you please elaborate more
about how we should do this and on what exactly is happening now? BTW, do we
currently raise the IncompatibleClassChangeError if the objectref's class
does not actually support the interface? Do we cache the interface tables
per class object and can we improve this cache search in the optimization?
In non trivial cases where many classes implement the same interface, the
cache search may be more expensive than  the slot look up.
  We could also virtualize and then devirtualize the interface invocation
when we can...somewhat like the jit dump above. What do you think?


> >* 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)
>
> > 3. Should I create a JIRA for the issue ASAP? :)


  I would say yes, let's create a JIRA issue

Thanks,


    Rana

---------------------------------------------------------------------
> 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
>
>

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