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

[Christian Hagedorn]

On Tue, 21 Oct 2025 16:31:48 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into elfdecoder-JDK-8334866
>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>  - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866
>  - 8334866: Cache debug_aranges for faster address lookups

This looks indeed very promising, thanks for working on improving the DWARF parsing speed! I always wanted to come back to the parser at some point to improve it by adding some caches but never found the time to do it. So, thanks a lot for addressing that :-)

I'm curious, how much speed-up did you get for some normal stack traces? You could, for example, try out [TestDwarf](https://github.com/chhagedorn/jdk/blob/master/test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java) which crashes the VM in some different ways and exercises the DWARF parser. No need to do some extensive benchmarking but would be interesting to see the effect of this patch on `TestDwarf`.

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

> 692:     found = _aranges_cache.find_compilation_unit_offset(offset_in_library, &compilation_unit_offset);
> 693:   } else {
> 694:     DWARF_LOG_INFO("Falling back to linear scan of .debug_aranges for '%s'", filepath());

Maybe add a comment here about when we need to fall back to a linear scan.

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

> 718: }
> 719: 
> 720: int DwarfFile::ArangesCache::compare_aranges_entries(const void* a, const void* b) {

Can you add a method comment here how the sorting is done?

src/hotspot/share/utilities/elfFile.hpp line 523:

> 521: 
> 522:   // Cache for .debug_aranges to enable binary search for address lookup
> 523:   struct ArangesCache {

I suggest to add some more details about why we have this cache and how it works. Could be here and/or at the appropriate methods.

src/hotspot/share/utilities/elfFile.hpp line 533:

> 531: 
> 532:     ArangesCache() : _entries(nullptr), _count(0), _capacity(0), _initialized(false), _failed(false) {}
> 533:     ArangesCache(ArangesCache&& other) : _entries(other._entries), _count(other._count), _capacity(other._capacity),

According to the style guide, move constructors/semantics is a feature we are undecided about and we should currently refrain from using them until a consensus is reached: [style guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#additional-undecided-features).

src/hotspot/share/utilities/elfFile.hpp line 956:

> 954:       return;
> 955:     }
> 956:     DebugAranges debug_aranges(const_cast<DwarfFile*>(this));

I don't think the `const_cast` is required since the constructor takes a non-const pointer.


Suggestion:

    DebugAranges debug_aranges(this);

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

PR Review: https://git.openjdk.org/jdk/pull/27337#pullrequestreview-3365144647
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451772244
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451792883
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451780142
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451785943
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451769349