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

[David Holmes]

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.

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
>>>
>