Bug ID: JDK-8303153 Native interpreter frame missing mirror

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 21
21 b22Fixed

While debugging JDK-8302350, it was found that an interpreter frame had an InstanceKlass* in the mirror_oop slot, where there should have been an oop of type java/lang/Class. That is, there should have been the mirror oop for the method holder, not the direct InstanceKlass*. How it ended up there is not clear, but since there is actually two InstanceKlass*es in that frame, it suggests that there have been recent changes to the interpreter frame layout, where there is now something called "extended_sp" also being stored? The extended_sp slot also has an (the same) InstanceKlass*.

Changeset: 5a259d87 Author: Fredrik Bredberg <fredrik.bredberg@oracle.com> Committer: Coleen Phillimore <coleenp@openjdk.org> Date: 2023-05-08 14:44:54 +0000 URL: https://git.openjdk.org/jdk/commit/5a259d875ee6ebd93d3c0932d50784021bc97ea2
08-05-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/13794 Date: 2023-05-04 08:00:23 +0000
04-05-2023
I took this bug thinking I can figure it what this is doing and why, but it looks a bit more complicated than I thought. The mirror needs to be stored in the frame for native calls also as it is on other platforms. // Get mirror __ load_mirror(r10, rmethod, r5, rscratch2); if (! native_call) { __ ldr(rscratch1, Address(rmethod, Method::const_offset())); __ ldrh(rscratch1, Address(rscratch1, ConstMethod::max_stack_offset())); __ add(rscratch1, rscratch1, MAX2(3, Method::extra_stack_entries())); __ sub(rscratch1, sp, rscratch1, ext::uxtw, 3); __ andr(rscratch1, rscratch1, -16); // Store extended SP and mirror __ stp(r10, rscratch1, Address(sp, 4 * wordSize)); // Move SP out of the way __ mov(sp, rscratch1); } else { // Make sure there is room for the exception oop pushed in case method throws // an exception (see TemplateInterpreterGenerator::generate_throw_exception()) __ sub(rscratch1, sp, 2 * wordSize); __ stp(zr, rscratch1, Address(sp, 4 * wordSize)); __ mov(sp, rscratch1); } Help!
25-04-2023
ILW = H (crash) L (unlikely) M (no workaround if native method unloaded) = P3
14-03-2023
Thanks [~aph].
14-03-2023
OK, I'll grab it.
10-03-2023
[~aph]I think the stack that Markus posted is really the problem in JDK-8302350, but if you look at generate_fixed_frame, if the method is native, you don't store the mirror in the mirror slot. I don't think you can do this. It would be hard to write a test case but you could unload the klass containing the native method, which the mirror is preventing you from doing.
10-03-2023
I should perhaps have a look, but I can't reproduce the problem at my end.
10-03-2023
The additional extended_sp slot is a cleanup by me.
10-03-2023
I was looking at generate_fixed_frame on aarch64 with Markus and noticed that the mirror oop isn't stored for native functions, which seems wrong. Is the additional extended_sp slot a result of Loom changes?
02-03-2023
ILW = HLH = P2
28-02-2023
Maybe related to JDK-8288971?
24-02-2023

Relates :	JDK-8302350 - JfrThreadSampler failed with "assert((is_native() && bci == 0) \|\| (!is_native() && 0 <= bci && bci < code_size())) failed: illegal bci: 0 for non-native method"
Relates :	JDK-8154580 - Save mirror in interpreter frame to enable cleanups of CLDClosure
Relates :	JDK-8288971 - AArch64: Clean up stack and register handling in interpreter