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

Christian Hagedorn chagedorn at openjdk.org
Wed Oct 22 11:52:14 UTC 2025


On Wed, 22 Oct 2025 11:10:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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
>
> 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?

I was about to ask the same. Since we have an easy caching mechanism and `.debug_aranges` does not change, we could hide the cache inside `DebugAranges`. Then from the `DwarfFile` point of view, it does not need to care about how the queries to `DebugAranges` are actually answered and we have a better separation of concerns.

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

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


More information about the hotspot-dev mailing list