Implement stack walking without AsyncGetCallTrace

[apangin]

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.

[toaler]

Hi @apangin any thoughts on when the features required to close this issue would be delivered? How potentially contributors help with the open work?

[apangin]

@toaler Not sure, but unlikely in the nearest release. Are you interested in some particular problem of AGCT?

[LuoXiaoyi]

I'd like to know when will the async-profiler support J9?

[apangin]

@LuoXiaoyi I'd like to know that as well ;) Pull requests are welcome!

[apangin]

I'm closing this issue as obsolete.
Further work on AsyncGetCallTrace replacement will be carried out in #795.