JDK-8170152 : WhiteBox testing of pd_get_top_frame_for_profiling
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-11-21
  • Updated: 2024-10-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8168445 - make pd_get_top_frame_for_profiling more robust
Relates :  
JDK-8169941 - CodeBlob::is_frame_complete_at() does not honor CodeOffsets::frame_never_safe
Relates :  
JDK-8321098 - Cooperative JFR Sampling
Relates :  
JDK-8284289 - JEP 435: Asynchronous Stack Trace VM API
Description
pd_get_top_frame_for_profiling can examine a thread at arbitrary points.  Some arbitrary points are more interesting than others.  Currently we rely on things like unpredictable thread scheduling and test crashes to find these points, but it takes a long time, and the set of failure points we find is just a random sample, not the complete set.

I suggest we add WhiteBox testing to deterministically test interesting code, starting with CodeBlobs.  We can insert special instructions that generate SIGSEGV or SIGILL at strategic places (for example where the stack pointer is being adjusted).  Then in the signal handler, call pd_get_top_frame_for_profiling, patch the instruction with a nop, and continue.
Comments
Actually, I was referring to the Java level Whitebox API that could provide a method that walks the stack on request from the application. However, this would only cover explicit hard-coded cases and not the interesting code that used to fail. So I think your approach is better.
22-11-2016
[~thartmann] from JDK-8169941 commented: "But wouldn't it be sufficient to have a Whitebox method that walks the current stack on request?" If you mean do a C call from arbitrary CodeBlob code, then yes it's possible, but if we want to continue executing, then we would need to save and restore all registers, conditional flags, etc. That's why I suggested using a signal handler instead, which will take care of saving and restoring the context for us.
21-11-2016