[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-compiler-dev mailing list