harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Egor Pasko (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-957) Devirtualize interface calls in DRLVM optimizing JIT-compiler (Jitrino.OPT)
Date Tue, 26 Sep 2006 03:58:51 GMT
    [ http://issues.apache.org/jira/browse/HARMONY-957?page=comments#action_12437725 ] 
            
Egor Pasko commented on HARMONY-957:
------------------------------------

First of all, this patch does NOT apply cleanly now in DrlEMImpl.cpp, devirtualizer.cpp, DrlVMInterface.h,
VMInterface.h, needs an update.
Secondly, although the patch introduces some performance gains, it is not stable yet (as reported
by Mikhail) and needs more tuning to be ready for DRLVM.
Now loop optimizations and profiling are a bit better after the BBC submission, which opens
more opportunities for development here. We will continue discussion on current status in
the dev list.

Thanks for reminder.


> Devirtualize interface calls in DRLVM optimizing JIT-compiler (Jitrino.OPT)
> ---------------------------------------------------------------------------
>
>                 Key: HARMONY-957
>                 URL: http://issues.apache.org/jira/browse/HARMONY-957
>             Project: Harmony
>          Issue Type: New Feature
>          Components: DRLVM
>         Environment: all
>            Reporter: Egor Pasko
>         Assigned To: Geir Magnusson Jr
>            Priority: Minor
>         Attachments: IntfcCaller.java, patch.zip
>
>
> Currently DRLVM does *not* devirtualize interface calls. 
> here are some ideas how to implement this feature (from easiest to complicated)
> 0) if there is only one loaded class to implement the interface, choose it
> 1) if there are more, choose the one with it's method invoked earlier (compiled  by some
JIT, possibly, some other JIT), 
> 2) if we have many candidate methods that are compiled, choose the most frequent  one
(need a method-entry profile)
> 3) initial compilation can devirtualize all possible dispatches and count their edge
frequencies so we can rely on basic profiler when choosing the best path (on recompilation)
> 4) implement a real value profiler - this is not an easy task, but may be reused in other
optimizations
> 5) 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message