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

dmitry.samersov dmitry.samersoff at bell-sw.com
Mon Sep 4 13:49:00 UTC 2017


Andrew,

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

1. This patch doesn't affect product build. On product build we have all
NMT frames inlined and don't need to skip anything.

I'll put these changes under #ifndef PRODUCT to make it clear visible.

2. NMT uses .symtab section and these symbols also available in release
build by default, unless someone manually strip libjvm.so

-Dmitry

On 04.09.2017 11:11, Andrew Dinn wrote:
> 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
> 




More information about the hotspot-runtime-dev mailing list