When capturing a stack trace for NMT, there is extra logic in place to skip frames that are only there to help capture the stacktrace. There is also logic to skip frames that are part of the allocation logic, such as AllocateHeap. This logic is fragile because it makes assumptions on what gets inlined and what doesn't, or when a tail call is used. The following bugs all addressed issues to clean up the frame skipping when it was incorrect:

JDK-8133749: os::current_frame() is not returning the proper frame on ARM and solaris-x64

JDK-8133747: NMT includes an extra stack frame due to assumption NMT is making on tail calls being used

JDK-8133740: NMT for Linux/x86/x64 and bsd/x64 slowdebug builds includes NativeCallStack::NativeCallStack() frame in backtrace

However, the likelihood of these types of issues cropping up again is high. This can happen whenever there are compiler changes, new platforms introduced, changes to compiler options, or changes to any code related to object allocation or frame skipping.

Also, in addition to the above issues that were fixed, there is still one outstanding issue with AllocateHeap not always being inlined. This is because ALWAYSINLINE is not honored for all platforms when doing debug builds.

The purpose of this RFE is to address this fragility issue, although at the moment there is no specific proposal on how to do this. It is unclear how we can get the frame skipping code to skip certain frames without knowing in advance if those frames will even be present. It might be necessary to push the "get fp" logic much further up the call chain, so it is guaranteed to be done inlined from the frame where we want the stack trace to begin, thus getting rid of the need to skip any frames.