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

[Andrew Dinn]

On 31/08/17 08:49, dmitry.samersov wrote:
> Please review:
> 
>     http://cr.openjdk.java.net/~dsamersoff/JDK-8163011/webrev.05/
> 
>     I would propose different approach to fix JDK-8133740
> platform-independent way: record all frames but strip unnecessary
> NMT-internal ones on printing.
> 
> This approach is safe (we don't depend to compiler inlining and we never
> strip non-NMT frames) and platform independent, but cost us some extra
> memory.
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).

In that case the NMT frames will be printed that would otherwise get
skipped, leading to differences in what calls are in the displayed in
the caller stack relative to the case where symbols are present. What is
more these changes would vary across architectures which use different
inlining strategies.

That may seem unimportant; one could take the view that an address which
is not associated with a symbolic name is just a meaningless hex value.
However, even without names it is still possible for someone who
understands the NMT code to correlate allocations which have the same
pattern of caller addresses, including correlation of such patterns
across builds or architectures. Throwing one or more NMT addresses into
the stack in place of a genuine caller will change these call patterns
in ways that might make it impossible to spot such correlations.

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