On 1/06/2019 4:15 pm, [email protected] wrote:
On 5/31/19 22:43, David Holmes wrote:
On 1/06/2019 3:09 pm, [email protected] 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, [email protected] 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
