Thawing frame can undo deoptimization

XMLWordPrintable

    • Type: Bug
    • Resolution: Unresolved
    • Priority: P4
    • 27
    • Affects Version/s: 25
    • Component/s: hotspot

      Method ThawBase::patch() has the following code:

        if (bottom) {
          ContinuationHelper::Frame::patch_pc(caller, _cont.is_empty() ? caller.pc()
                                                                       : StubRoutines::cont_returnBarrier());
        } else if (caller.is_compiled_frame()){
          // caller might have been deoptimized during thaw but we've overwritten the return address when copying f from the heap.
          // If the caller is not deoptimized, pc is unchanged.
          ContinuationHelper::Frame::patch_pc(caller, caller.raw_pc());
        }
        ...

      The `else` branch is executed regardless of whether the frame was deoptimized during thaw, under the assumption that, if it was not, the pc written will be same as existing one. The problem with that assumption is that if the frame was already deoptimized before thaw, caller.raw_pc() will not return the deoptimized pc but the original one before deoptimization. This is because when creating the frame object, the actual frame is not yet laid out in the stack and so caller.is_deoptimized_frame() is always false. Here is the relevant comment from ThawBase::recurse_thaw_compiled_frame:

        // new_stack_frame must construct the resulting frame using hf.pc() rather than hf.raw_pc() because the frame is not
        // yet laid out in the stack, and so the original_pc is not stored in it.
        // As a result, f.is_deoptimized_frame() is always false and we must test hf to know if the frame is deoptimized.

      This issue was uncovered by JDK-8370177.

            Assignee:
            Patricio Chilano Mateo
            Reporter:
            Patricio Chilano Mateo
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: