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

[Dmitry Samersoff]

Andrew,

On 08/31/2017 11:56 AM, Andrew Dinn 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).

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.

With the current solution we skip two frames ever if they don't belong
to NMT (e.g. call to os::attempt_reserve_memory_at was skipped in the
example below). IMHO, it's worse than print unwilling NMT symbols.


With current SKIP machinery

1. ReservedHeapSpace::try_reserve_heap(unsigned long, unsigned long,
bool, char*)+0x1ed

2. ReservedHeapSpace::try_reserve_range(char*, char*, unsigned long,
char*, char*, unsigned long, unsigned long, bool)+0x121

3. ReservedHeapSpace::initialize_compressed_heap(unsigned long, unsigned
long, bool)+0x3fa

4. ReservedHeapSpace::ReservedHeapSpace(unsigned long, unsigned long,
bool)+0xa8
                             (reserved=946176KB, committed=59392KB)

Without current SKIP machinery:

1. NativeCallStack::NativeCallStack(int, bool)+0x68

2. os::attempt_reserve_memory_at(unsigned long, char*)+0x6b

3. ReservedHeapSpace::try_reserve_heap(unsigned long, unsigned long,
bool, char*)+0x1ed

4. ReservedHeapSpace::try_reserve_range(char*, char*, unsigned long,
char*, char*, unsigned long, unsigned long, bool)+0x121
                             (reserved=946176KB, committed=59392KB)


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

If different architecture implements different inlining strategy, I
would expect difficulty in finding correlations between them with or
without this patch.

-Dmitry


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