| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8174449 | 10 | Douglas Simon | P3 | Resolved | Fixed | b01 |
The ResolvedJavaMethod.canBeInlined method captures 2 different constraints on inlining:
1. Whether the method has an explicit directive (e.g., -XX:CompileCommand=dontinline) or a hotspot recognized annotation (e.g., @DontInline).
2. Whether hotspot has marked it not compilable for policy reasons (e.g., failed compilation earlier or has a bytecode breakpoint).
Some JVMCI clients (such as Truffle partial evaluation) are explicitly interested in the former without concern for the latter. To support this oversight, a separate ResolvedJavaMethod.hasNeverInlineDirective method must be added to JMVCI.
1. Whether the method has an explicit directive (e.g., -XX:CompileCommand=dontinline) or a hotspot recognized annotation (e.g., @DontInline).
2. Whether hotspot has marked it not compilable for policy reasons (e.g., failed compilation earlier or has a bytecode breakpoint).
Some JVMCI clients (such as Truffle partial evaluation) are explicitly interested in the former without concern for the latter. To support this oversight, a separate ResolvedJavaMethod.hasNeverInlineDirective method must be added to JMVCI.
- backported by
-
JDK-8174449 [JVMCI] add ResolvedJavaMethod.hasNeverInlineDirective
-
- Resolved
-
- relates to
-
JDK-8173699 Crash during deoptimization with "assert(result == __null || result->is_oop()) failed: must be oop"
-
- Closed
-