| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8045261 | 8u25 | Roland Westrelin | P3 | Resolved | Fixed | b01 |
| JDK-8037547 | 8u20 | Roland Westrelin | P3 | Resolved | Fixed | b07 |
| JDK-8053261 | emb-8u26 | Roland Westrelin | P3 | Resolved | Fixed | b17 |
When a node has a speculative type, and parsing encounter extra profiling data, the extra profiling data is ignored. So profiling data coming from profile points closer to the root of the compilation is favored which I think makes sense: it's the data that is most specific to the context of this compilation that we rely on.
There are exception to this in practice. For instance:
m1() {
m3();
}
m() {
m1();
m2();
}
Let's say, m3() and m2() have profile data for the same node. The first profile data to be encountered during parsing is from m3() and profile data from m2() is ignored but profile data from m2() is the one that is actually the most specific and is the one that should be favored.
There are exception to this in practice. For instance:
m1() {
m3();
}
m() {
m1();
m2();
}
Let's say, m3() and m2() have profile data for the same node. The first profile data to be encountered during parsing is from m3() and profile data from m2() is ignored but profile data from m2() is the one that is actually the most specific and is the one that should be favored.
- backported by
-
JDK-8037547 Type speculation should favor profile data from outermost inlined method
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
JDK-8031751 When doing multiple identical runs in the same environment, benchmark peak scores vary widely for octane benchmarks on Nashorn
-
- Closed
-