[aarch64-port-dev ] jdk11 fastdebug seems to have slowed down.

[Dave Nuechterlein]

I wish I had better records on what used to work well.  The "normal" fastedebug slowdown of about 20% was on a jdk trunk tree from right before the jdk -> jdk11 spin off.  I am using a jdk11 that I have rebuilt several times in the last week, including this morning.  I am still seeing the massive slowdown with this morning's updates.

-----Original Message-----
From: Andrew Dinn <adinn at redhat.com> 
Sent: Wednesday, August 1, 2018 10:23 AM
To: Dave Nuechterlein <dnuechte at amperecomputing.com>; aarch64-port-dev at openjdk.java.net
Cc: Kevin Smith <kevin.smith at amperecomputing.com>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] jdk11 fastdebug seems to have slowed down.

[NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.] ________________________________________________________________________________________________________________________

Hi Dave,

On 01/08/18 16:53, Dave Nuechterlein wrote:
> I have traced the difference down to
> src/hotspot/share/code/compiledMethod.hpp.  The 
> PcDescContainer::find_pc_desc_internal seems to be doing a lot of 
> searching of long lists.
>
> This obviously might not be a Aarch64 port issue, but rather a hotspot 
> issue.  If anyone here has any experience with the whole 
> PcDescContainer, or has seen fastdebug execution times escalating, I 
> would appreciate getting any kind of help.  The PcDescContainer 
> appears to be some way for a method to understand its calling 
> hierarchy.

Yes, a PcDesc is used to translate a JITted code location to a bytecode location and, from there, potentially to a source code line. It is needed in order to generate correct stack traces.

PcDesc entries can also be used to associate line numbers with arbitrary JITted code but there is no guarantee that there will be a useful PcDesc that you can reliably associate with any given JITted PC. Safepoints, call locations, exception throw points and traps should be mapped. Other locations may not have an associated PcDesc and searching (forwards or
backwards) for the nearest one to a given pc address may or may not land you at a related source line.

If you are seeing a slow down because of long searches of PcDesc lists then this suggests that at some point someone has added more PcDesc entries. I don't recall seeing any change go in that might have led to this but perhaps the hotspot-compiler or runtime devs (in CC) might know of one. What was the jdk release you are comparing against where this slowdown did not show?

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