There is a number of problems with AsyncGetCallTrace API.

• It is not accurate: sometimes it can point to neighbour methods. See Accuracy of heap profile #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 Alloc smoke test fails with java9 #60.

• It requires preloading of all jmethodIDs thus resulting in startup time overhead. See Measure and document overhead #14 (comment).

• It does not distinguish between interpreted, compiled and inlined frames.

• In rare cases it may crash JVM. See async-profiler causes SIGSEGV nmethod::get_deopt_original_pc #73.

• -XX:MaxJavaStackTraceDepth unobviously affects collected stack traces. See Profiler doesn't work when MaxJavaStackTraceDepth set to -1 #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.