JDK-6384206 : Phis which are later unneeded are impairing our ability to inline based on static types
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,solaris_9
  • CPU: x86,sparc
  • Submitted: 2006-02-10
  • Updated: 2022-10-26
  • Resolved: 2008-10-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
While investigating the performance of HashMap.get(k) I noticed that in cases where the static type of k is available C2 isn't taking advantage of the information in making it's inline decisions for get.  The problem is that Phis which are introduced for the join of a diamond aren't being eliminated aggressively during parsing when one of the paths is proved dead.  Additionally unneeded loop phis are hiding the type k in the search loop, impairing the inlining of equals.  Post parse inlining which remove the need for aggressive elimination of phis but for now we need a better strategy for simplification of phis.

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/194b8e3a2fc4

EVALUATION Some simple changes to parse collapse phis for dead codes paths. A better strategy is to rely on RPO for parse order and when you reach a block with unparsed predecessors, assume they are dead unless your block is a backward branch target. Eliminating phis for loops requires some analysis though it can be very cheap if we are looking for the simple case.