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

[Aleksey Shipilev]

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 very promising. I think we need to tighten up the style before we can integrate. @chhagedorn, who I see wrote the significant if not the entire part of this might want to take a look as well.

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

> 693:   } else {
> 694:     DWARF_LOG_INFO("Falling back to linear scan of .debug_aranges for '%s'", filepath());
> 695:     DebugAranges debug_aranges(this);

This honestly looks like we want to pull `DebugAranges` up to be a permanent member of `DwarfFIle`, and put the cache there? This would also resolve fairly awkward passing `ArangeCache&` around, since `DebugAranges` itself would do most of the heavy-lifting, including managing its own (internal) cache. Is there anything in the way of doing so?

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

> 742:   assert(cache._count == 0, "need fresh cache");
> 743:   assert(!cache._initialized, "need fresh cache");
> 744:   assert(!cache._failed, "need fresh cache");

I think it makes sense to test the flags only.

Suggestion:

  assert(!cache._initialized && !cache._failed, "Do it once");

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

> 804:   return;
> 805: 
> 806: cleanup_and_fail:

Goto statements are against HS code style: https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md. Consider pulling this cleanup code into `ArangesCache` helper method, and then call it like this:


 if (failing-condition) {
   cache.destroy();
   return;
 }

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

> 547:    private:
> 548:     static int compare_aranges_entries(const void* a, const void* b);
> 549:     void sort() {

Just inline it into the only use?

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

PR Review: https://git.openjdk.org/jdk/pull/27337#pullrequestreview-3365234528
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451728417
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451661420
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451688112
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2451734051