-
Bug
-
Resolution: Fixed
-
P3
-
8-aarch64, 11, 12, 13
-
b27
-
aarch64
-
linux
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8215636 | 13 | Andrew Dinn | P3 | Resolved | Fixed | b01 |
JDK-8217063 | 12.0.1 | Andrew Dinn | P3 | Resolved | Fixed | b03 |
JDK-8288391 | 11.0.17-oracle | Fairoz Matte | P3 | Resolved | Fixed | b01 |
JDK-8289591 | 11.0.16.0.1-oracle | Fairoz Matte | P3 | Closed | Fixed | b01 |
JDK-8221464 | 11.0.4 | Andrew Dinn | P3 | Resolved | Fixed | b01 |
JDK-8260818 | openjdk8u292 | Andrew Hughes | P3 | Resolved | Fixed | b01 |
vmTestbase/vm/mlvm/indy/stress/jdi/breakpointInCompiledCode/Test.java
vmTestbase/vm/mlvm/meth/func/jdi/breakpoint/Test.java
When the interpreter dispatches a method, it should check the JavaThread::interp_only_mode_offset() field in the thread structure, and if it's non-zero call the interpreted entry point even if a compiled entry exists. When we use a java.lang.invoke.MethodHandle to invoke a method, the method dispatch is instead handled by a special intrinsic that's implemented in methodHandles_aarch64.cpp. This eventually calls MethodHandles::jump_from_method_handle which checks the JVMTI interp_mode_only flag. But the test is incorrect.
- backported by
-
JDK-8215636 AArch64: method handle invocation does not respect JVMTI interp_only mode
- Resolved
-
JDK-8217063 AArch64: method handle invocation does not respect JVMTI interp_only mode
- Resolved
-
JDK-8221464 AArch64: method handle invocation does not respect JVMTI interp_only mode
- Resolved
-
JDK-8260818 AArch64: method handle invocation does not respect JVMTI interp_only mode
- Resolved
-
JDK-8288391 AArch64: method handle invocation does not respect JVMTI interp_only mode
- Resolved
-
JDK-8289591 AArch64: method handle invocation does not respect JVMTI interp_only mode
- Closed
- relates to
-
JDK-8257192 Integrate AArch64 JIT port into 8u
- Resolved