RFR(M): JDK-8163011: AArch64: NMT detail stack trace cleanup

[Andrew Dinn]

On 03/09/17 19:12, Dmitry Samersoff wrote:
> On 08/31/2017 11:56 AM, Andrew Dinn wrote:
>> I don't think this is going to work well when symbols are not present
>> (meaning you cannot resolve return pc addresses to function names).
> 
> On elf platforms, NMT uses .symtab section of libjvm.so and it's hard to
> me to imagine the situation where someone has stripped slowdebug build.

Yes, but NMT also works (and is meant to work) on product builds where
the required symbols are not available.

> If different architecture implements different inlining strategy, I
> would expect difficulty in finding correlations between them with or
> without this patch.
Perhaps, but the status quo is code which avoids any differences in
where the stack trace starts caused by inlining. The current problem is
that this is fragile wrt to changes in the C++ compiler. Your fix
introduces an extra type of variation in the stack traces when symbols
are not present (it does not mitigate other effects of different
inlining strategies).

So, I am merely pointing out that this is a use case that will occur
(people /will/ use NMT in production deployments even if only in a
sandbox) and identifying the variation in output as a limitation to be
weighed in the balance. I think, on balance, I prefer the status quo to
your attempt to mitigate a /potential/ future risk. I don't suppose most
users will care about which hex addresses they see in their backtraces
so to them it will be moot.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander