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

[serguei.spitsyn at oracle.com]

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.


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