VM structs stack walker fails to walk after an interpreter method is retransformed/redefined and still on stack
Describe the bug
I observed a bug related to VM structs stack walker.
Reproduce steps is:
- A running method is executed by interpreter, for long time
- Retransform/Redefine the class
- The method still on stack, then profiler fails to unwind this method
The result is as the following flame graph. On the left, before retransformation/redefinition, the method is unwound successfully. On the right, after retransformation/redefinition, failed to unwind this method.
After investigation, I found the cause is the jmethodId contents check.
If a method is retransformed/redefined, the Method address (Method*, this in the line above) does not equal to the Method address stored in jmethodId (*(VMMethod**)method_id).
This bug does not exist in the AsyncGetCallTrace API, because it just return the jmethodId in cache, which points to the new Method.
In some applications with deep stack trace, the bottom methods has a high probability of not being compiled by C1/C2.
Aside from removing this check, I can't think of any other good way to fix it.
Expected vs. actual behavior
Expected: The stack trace after retransformed/redefined is still correct.
Reproduction Steps
As described above.
Additional Information/Context
No.
Async-profiler version
Latest
Environment details
Ignored.
Source: async-profiler/async-profiler