Indeed, JFR (or AsyncGetCallTrace) callstacks can not be blindly trusted.
What likely happens here is that StringBuilder.setLength() is inlined along
with its callees (Array.fills among them) and callers into some dynamically
compiled method. When that method is asynchronously interrupted at an
arbitrary point, in order to reconstruct the full Java callstack JFR has to
rely on the PC to Java callstack fragment mapping provided by the JIT
compiler for this method. As JDK-8022893 demonstrates, the compiler is not
particularly good at that. To test this theory one would need to map events
attributed to Arrays.fill() in the provided context to PC's in the actual
compiled method, figure out what Java callstack fragments were provided by
JIT for those PC's and see whether those fragments were correct (not
trivial).
Why isn't this mapping problem revealed in exception callstacks generated
by runtime? Exceptions like NPE do not happen at arbitrary points in code
and, presumably, were easier to report and escalate to developers (it's
runtime behavior after all). More subtle corner cases visible only with
sophisticated tools get lower priority and remain in the backlog for years,
if not merely discarded.
-- Oleg
On Friday, December 1, 2017 at 9:29:44 PM UTC-8, Remko Popma wrote:
>
> For background, see https://stackoverflow.com/q/47590263/1446916
>
> Apangin’s answer seems plausible, would like to hear insights from people
> on this list.
>
> Remko
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
