You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Egor Pasko (JIRA)" <ji...@apache.org> on 2006/07/24 06:53:13 UTC
[jira] Created: (HARMONY-957) Devirtualize interface calls in DRLVM
optimizing JIT-compiler (Jitrino.OPT)
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
Priority: Minor
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
[jira] Assigned: (HARMONY-957) Devirtualize interface calls in
DRLVM optimizing JIT-compiler (Jitrino.OPT)
Posted by "Geir Magnusson Jr (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-957?page=all ]
Geir Magnusson Jr reassigned HARMONY-957:
-----------------------------------------
Assignee: (was: Geir Magnusson Jr)
Dassigning as it's a placeholder for now
> 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
> 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
[jira] Updated: (HARMONY-957) Devirtualize interface calls in DRLVM
optimizing JIT-compiler (Jitrino.OPT)
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-957?page=all ]
Gregory Shimansky updated HARMONY-957:
--------------------------------------
Patch Info: (was: [Patch Available])
Removed patch available status not to create confusion.
> 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
> 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
[jira] Commented: (HARMONY-957) Devirtualize interface calls in
DRLVM optimizing JIT-compiler (Jitrino.OPT)
Posted by "Egor Pasko (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-957?page=comments#action_12445086 ]
Egor Pasko commented on HARMONY-957:
------------------------------------
Geir, "patch available" status is great! But, unfortunately, not for this issue. The patch (attached) is not mature enough, it does not solve the problem as we want it to. So, I would consider such situations as "patch NOT available".
> 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
> 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
[jira] Updated: (HARMONY-957) Devirtualize interface calls in DRLVM
optimizing JIT-compiler (Jitrino.OPT)
Posted by "Geir Magnusson Jr (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-957?page=all ]
Geir Magnusson Jr updated HARMONY-957:
--------------------------------------
Patch Info: [Patch Available]
> 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
> 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
[jira] Commented: (HARMONY-957) Devirtualize interface calls in
DRLVM optimizing JIT-compiler (Jitrino.OPT)
Posted by "Egor Pasko (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (HARMONY-957) Devirtualize interface calls in
DRLVM optimizing JIT-compiler (Jitrino.OPT)
Posted by "Geir Magnusson Jr (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-957?page=comments#action_12439338 ]
Geir Magnusson Jr commented on HARMONY-957:
-------------------------------------------
Would you prefer that we close this or keep it open, waiting for the new patch?
> 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
[jira] Commented: (HARMONY-957) Devirtualize interface calls in
DRLVM optimizing JIT-compiler (Jitrino.OPT)
Posted by "Geir Magnusson Jr (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-957?page=comments#action_12437207 ]
Geir Magnusson Jr commented on HARMONY-957:
-------------------------------------------
is this patch still relevant?
> 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
[jira] Assigned: (HARMONY-957) Devirtualize interface calls in
DRLVM optimizing JIT-compiler (Jitrino.OPT)
Posted by "Geir Magnusson Jr (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-957?page=all ]
Geir Magnusson Jr reassigned HARMONY-957:
-----------------------------------------
Assignee: Geir Magnusson Jr
> 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
[jira] Updated: (HARMONY-957) Devirtualize interface calls in DRLVM
optimizing JIT-compiler (Jitrino.OPT)
Posted by "Mikhail Fursov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-957?page=all ]
Mikhail Fursov updated HARMONY-957:
-----------------------------------
Attachment: patch.zip
Patch enables interface calls devirtualization.
Check "[drlvm] interface call devirtualization" mail thread for details.
> 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
> 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
[jira] Updated: (HARMONY-957) Devirtualize interface calls in DRLVM
optimizing JIT-compiler (Jitrino.OPT)
Posted by "Egor Pasko (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-957?page=all ]
Egor Pasko updated HARMONY-957:
-------------------------------
Attachment: IntfcCaller.java
Benchmark to detect interface call optimizations.
> 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
> Priority: Minor
> Attachments: IntfcCaller.java
>
>
> 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
[jira] Commented: (HARMONY-957) Devirtualize interface calls in
DRLVM optimizing JIT-compiler (Jitrino.OPT)
Posted by "Egor Pasko (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-957?page=comments#action_12439379 ]
Egor Pasko commented on HARMONY-957:
------------------------------------
I would prefer to keep it. That would be a visible issue that someone can take and improve. Someone, feel free to take it and ask how we can improve it in the dev list :)
> 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