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

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Sat Jun 1 05:09:10 UTC 2019


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.

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



More information about the serviceability-dev mailing list