On Fri, 7 Nov 2025 15:31:27 GMT, Vladimir Kozlov <[email protected]> wrote:
>>> Thanks @ruben-arm. Let's go with this clean back out for now - testing just >>> came back clean. Once you have the REDO ready, I can submit some more >>> sophisticated testing to make sure it addresses the issues we're seeing. >> >> @TobiHartmann, I would appreciate it if you could initiate the extended >> testing for this PR. > > @ruben-arm what was the issue in the original changes? @vnkozlov, the `NativePostCallNop::check` https://github.com/openjdk/jdk/blob/e34a831814996be3e0a2df86b11b1718a76ea558/src/hotspot/cpu/x86/nativeInst_x86.hpp#L584 was reading 4 bytes from the perceived call site. That works when the check happens for an actual call site, as the post-call NOP sequence is always longer than 4 bytes. However, it fails in case the return address in the stack frame, during deoptimization, is patched to point to the deoptimization stub code entry point. With the change, the distance between the entry point and end of code blob can now be just 2 bytes - consequently the 4-bytes read would read outside the code blob. The proposed fix is to split the read in the post-call NOP check into two 2-byte reads. If first read+comparison doesn't confirm it might be a post-call NOP sequence (it never will for the deoptimization stub code entry point) the second read wouldn't happen. I initially missed this issue - having incorrectly concluded that the `jmp` at the entry point will take 5 bytes in size instead of 2 bytes. https://github.com/openjdk/jdk/pull/28192/commits/7bb43523b3c9d1495d72a5bc75c3912c3f51e64c should address this issue by splitting the faulting read into two. It also adjusts the expected size of deoptimization handler stub code to 7 bytes in total instead of the incorrect estimate of 10 bytes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28192#issuecomment-3503297153
