-
Enhancement
-
Resolution: Fixed
-
P4
-
9
-
b55
-
generic
-
generic
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8085612 | emb-9 | Attila Szegedi | P4 | Resolved | Fixed | team |
| JDK-8087043 | 8u65 | Attila Szegedi | P4 | Resolved | Fixed | b01 |
| JDK-8075005 | 8u60 | Attila Szegedi | P4 | Resolved | Fixed | b08 |
| JDK-8138459 | emb-8u65 | Unassigned | P4 | Resolved | Fixed | b01 |
| JDK-8076957 | emb-8u60 | Attila Szegedi | P4 | Resolved | Fixed | team |
CodeGenerator code for loading a JoinPredecessorExpression (JPE) ignores whether it is the current discard. Combined with the fact that for loop's modify expressions are now JPEs this causes a typical postincrement in them to have unnecessary DUP/POP pairs, e.g. a typical for-loop "++i" will now be
iload 3
iconst_1
invokedynamic iadd(II)I
dup
istore 3
pop
The issue is bit more widespread than that, though -- there's a lot of other expressions that could also better discard their subexpressions, e.g. COMMARIGHT. Even if the JPE is fixed, a for loop having "++i, ++j" will not do a discard on ++j as COMMARIGHT doesn't do loadAndDiscard on its RHS regardless of wether it itself should be discarded. Basically, a review of discard logic would be in order.
iload 3
iconst_1
invokedynamic iadd(II)I
dup
istore 3
pop
The issue is bit more widespread than that, though -- there's a lot of other expressions that could also better discard their subexpressions, e.g. COMMARIGHT. Even if the JPE is fixed, a for loop having "++i, ++j" will not do a discard on ++j as COMMARIGHT doesn't do loadAndDiscard on its RHS regardless of wether it itself should be discarded. Basically, a review of discard logic would be in order.
- backported by
-
JDK-8075005 More aggressive value discarding
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
JDK-8079424 Code generator emits an extra POP for discarded boolean logical operation
-
- Resolved
-
(1 relates to)