Implement stack walking without AsyncGetCallTrace #66
Labels
Comments
Closed
This was referenced Feb 23, 2018
Hi @apangin any thoughts on when the features required to close this issue would be delivered? How potentially contributors help with the open work? |
@toaler Not sure, but unlikely in the nearest release. Are you interested in some particular problem of AGCT? |
I'd like to know when will the async-profiler support J9? |
@LuoXiaoyi I'd like to know that as well ;) Pull requests are welcome! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There is a number of problems with
AsyncGetCallTrace
API.It is not accurate: sometimes it can point to neighbour methods. See #51 and JDK-8022893.
It incorrectly handles certain corner cases. See JDK-8178287.
It fails to walk through VM frames in Oracle JDK 9. See #60.
It requires preloading of all jmethodIDs thus resulting in startup time overhead. See #14 (comment).
It does not distinguish between interpreted, compiled and inlined frames.
In rare cases it may crash JVM. See #73.
-XX:MaxJavaStackTraceDepth
unobviously affects collected stack traces. See #89.Unloaded methods appears in the profile as
jvmtiError 23
.Cannot walk stack traces from methods compiled with Graal.
= has workaround in async-profiler
The idea is to implement Java stack walking on our own without relying on AGCT. Since the agent runs in the context of JVM, it can access VM structures, especially those exported through VMStructs. It should be possible to replicate stack walking logic of the VM inside async-profiler, though it might be challenging. The main risk is that differrent versions of JVM may have different stack layout, but VMStructs along with special handling of the known versions is likely to help.
The text was updated successfully, but these errors were encountered: