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

[Thomas Stüfe]

Hi,





On Thu, Aug 31, 2017 at 10:56 AM, Andrew Dinn <adinn at redhat.com> wrote:

> 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.
>
>
The PCs of the last n frames of the callstacks collected by
NativeCallStack() should always be the same, or?

e.g. on Windows:

NativeCallStack::NativeCallStack(int toSkip, bool fillStack) + x
os::get_native_stack + y
RtlCaptureStackBackTrace

I assume that x and y would always be the same?

If this is true, could we not find out these PCs in advance, store them,
and during printing compare the to be printed PCs with the stored ones,
skipping printing if they match?

To find out those PCs in advance, one could instantiate a NativeCallStack
object, let it fill in the callstack, then store the PCs of the last n
frames up to the current frame.

Sorry if this does not work, I did not yet try it out.



> 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
>


Kind Regards, Thomas