On Wed, 10 Jun 2026 14:04:06 GMT, Patricio Chilano Mateo <[email protected]> wrote:
> Please review this small fix. After JDK-6960970, a `NotifyFramePop` request > targeting a virtual thread can lead to deoptimizing a compiled frame that is > currently in the heap. When the frame deoptimized is the top frame in the > `stackChunk`, the chunk’s `pc` field must be updated as well. > > I refactored `JvmtiEnvBase::set_frame_pop` to separate between the heap vs > stack frame cases, instead of the current logic which is based on mounted vs > unmounted. Also helper `frame::deoptimize(JavaThread*, stackChunkOop)` is > added to encapsulate the deopt logic. > > I verified the test doesn’t crash anymore and also tested in mach5 tiers1-6. > > Thanks, > Patricio > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). > This fix is good. Also, it simplifies the set_frame_pop() and makes it more > elegant. > It seems that the fixVersion does not match the repo version. > Yes, that will just create a backport for 27 once this gets integrated. Thanks for the review Serguei! ------------- PR Comment: https://git.openjdk.org/jdk/pull/31456#issuecomment-4681972932
