RFR: 8334866: Improve Speed of ElfDecoder source search [v5]

[Kerem Kat]

On Fri, 24 Oct 2025 17:27:45 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
>> 
>> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
>> 
>> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.
>
> Kerem Kat has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into elfdecoder-JDK-8334866
>  - fix DWARF_LOG_INFO
>  - Comment on ArangesCache
>  - Fix secondary sort order and comment
>  - Remove move ctor of ArangesCache
>  - Clarify when we can fallback to linear scan, which doesn't seem to allocate on the heap
>  - Move ArangesCache into DebugAranges, and DebugAranges into DwarfFile
>  - inline sort
>  - goto considered harmful
>  - Use QuickSort::sort instead of qsort
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/9c486911...ae72cae8

src/hotspot/share/utilities/elfFile.cpp line 818:

> 816:     case CacheHint::VALID:
> 817:       return _cache.find_compilation_unit_offset(offset_in_library, compilation_unit_offset);
> 818:     case CacheHint::TRY_LINEAR_SCAN:

Should we eliminate the fallback?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2461372847