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

[Vladimir Kozlov]

Which test shows slowdown? Whould be nice to find when (which jdk11 
build) it started?

Is it possible that find_pc_desc_internal() is called more then before?

Is it linear_search() takes long? It is called only in debug VM. Or 
loops in find_pc_desc_internal()?:

http://hg.openjdk.java.net/jdk/jdk/file/b095f437af22/src/hotspot/share/code/nmethod.cpp#l1822

I don't see any big changes in this code in jdk 11. Coleen removed 
ValueObj (8173070) but it was "" empty for gcc for long time.

Vladimir

On 8/1/18 9:23 AM, Andrew Dinn wrote:
> 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
>