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

Andrew Haley aph at redhat.com
Thu Aug 2 20:18:22 UTC 2018

On 08/02/2018 09:02 AM, Andrew Dinn wrote:
> On 01/08/18 18:14, Andrew Haley wrote:
>> On 08/01/2018 05:23 PM, Andrew Dinn wrote:
>>> 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?
>> There's no need to speculate.  Just run the fastdebug build in a debugger and
>> see who's calling find_pc_desc_internal().  It shouldn't take any more than half
>> an hour to find out.
> Well, running up a debugger is almost always a good idea.
> However, I know (having done what you suggest in the past) that PcDesc
> searches have always been executed as part of the assert/verify code
> that executes in fastdebug mode (but not in product mode). The problem
> may possibly be caused by new calls but, given the description of what
> Dave observed in the latest build (and, by implication, did nto see in
> previous builds), it sounds like the problem is more PcDesc data.
> Tracking the calls might help pin down the former problem but I doubt it
> will explain much in the latter case. If it is that second case then
> tracking the calls which create the data would be a good idea. At the
> least it would pin down places to look for recent changes.

It's being called a huge number of times from nmethod::verify_scopes.
This is used at every single scope, and it misses the PC cache because
the methods are always new.  This means you have to search.

Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the hotspot-runtime-dev mailing list