| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2201427 | 7 | Tom Rodriguez | P3 | Closed | Fixed | b115 |
| JDK-2205829 | 6u25 | Tom Rodriguez | P3 | Resolved | Fixed | b01 |
| JDK-2201487 | 6u23 | Tom Rodriguez | P3 | Resolved | Fixed | b02 |
| JDK-2200030 | 6u22m | Tom Rodriguez | P3 | Resolved | Fixed | b02 |
| JDK-2200006 | 6u21p | Tom Rodriguez | P3 | Resolved | Fixed | b04 |
| JDK-2200385 | hs20 | Tom Rodriguez | P3 | Closed | Fixed | b02 |
The logic for the new OptimizeFill code misses a case where the Phi usage is different than expected. Sometimes during transformation of the loop there are uses of the memory phi outside the loop. This seems like a benign bug but it interferes with the fill matching logic that assumes the store in the loop should be the outgoing state. The fix is to allow the phi to be used outside the loop and replace it with the outgoing memory of the call to the fill.
- backported by
-
JDK-2200006 OptimizeFill misses some cases with an odd memory graph
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Closed
-
-
-
- Closed
-
(1 backported by)