RFC (csr): 8225142: JVMTI spec incorrectly states that PopFrame can not be called on the current thread

[serguei.spitsyn at oracle.com]

On 6/2/19 05:34, David Holmes wrote:
> On 1/06/2019 4:15 pm, serguei.spitsyn at oracle.com wrote:
>> On 5/31/19 22:43, David Holmes wrote:
>>> On 1/06/2019 3:09 pm, serguei.spitsyn at oracle.com wrote:
>>>> Hi David,
>>>>
>>>> Thank you for looking at it!
>>>>
>>>>
>>>> On 5/31/19 9:47 PM, David Holmes wrote:
>>>>> Hi Serguei,
>>>>>
>>>>> Sorry but I'm rather confused - what does it mean to do a 
>>>>> "popframe" on the current thread?
>>>>
>>>> I was confused too.
>>>> We have several JVMTI tests that calls PopFrame in event callbacks.
>>>>   For instance (see also: popframe006, popframe007, popframe008):
>>>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe010
>>>>
>>>> This test gets a breakpoint event and in the callback:
>>>>   - clears the breakpoint
>>>>   - enables single stepping
>>>>   - calls the PopFrame
>>>>
>>>> This seems to be working.
>>>
>>> Okay that makes sense. I hadn't thought about callbacks executing in 
>>> the current thread and causing it to back itself up.
>>
>> Not sure, I understand you what you mean by "causing it to back 
>> itself" up.
>> The PopFrame will pop the top-most java frame, not the callback frame.
>> The two top-most java frames are marked for deoptimization and the 
>> pending_popframe bit is set.
>
> That's basically what I meant. The current frame (call it m()) hits 
> the breakpoint and the thread executes the callback which pops the 
> current frame winding the thread back to the point where m() is called.

Great!

Thanks,
Serguei


>
> David
>
>>
>>
>>>>> The whole point of popframe is to suspend a target thread when it 
>>>>> is executing a specific method, and then call popframe to "back 
>>>>> up" the thread to the point where it will call that method again 
>>>>> when resumed. How does that work with the current thread?
>>>>
>>>> Probably, the most interesting question is:
>>>>   How will the target thread continue its execution?
>>>>
>>>> As I understand, it will be single stepping.
>>>
>>> I would hope so in the scenario you describe. But presumably the 
>>> callback could just clear the breakpoint and do a popframe and so 
>>> execution would continue as before?
>>
>> After the event callback returns the execution is continued in the 
>> interp-only mode.
>> The actual work is done by the remove_activation_preserving_args.
>>
>> Thanks,
>> Serguei
>>
>>>
>>> Cheers,
>>> David
>>> ------
>>>
>>>> In such a case, the thread is executed in the interp-only mode.
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 1/06/2019 1:59 pm, serguei.spitsyn at oracle.com wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Please comment or.and review the following CSR.
>>>>>>
>>>>>> The CSR:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225142
>>>>>>
>>>>>> The bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8205126
>>>>>>
>>>>>> Updated JVMTI spec:
>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti.html 
>>>>>>
>>>>>>
>>>>>>
>>>>>> Specdiff:
>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8205126-jvmti-spec-popframe.1/jvmti-specdiff/ 
>>>>>>
>>>>>>
>>>>>>
>>>>>> Summary:
>>>>>>    The JVMTI PopFrame() spec does not match the implementation.
>>>>>>    It says the  specified thread can not be the current thread.
>>>>>>    The fix aligns:
>>>>>>     - spec with implementaion
>>>>>>     - PopFrame spec with ForceEarlyReturn spec
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>
>>