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). Yes this is quite nice. Is there anywhere else where we might deoptimize with the top frame that is a heap frame? This is a good encapsulation of that. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/31456#pullrequestreview-4508680451
