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