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

Aleksey Shipilev shade at openjdk.org
Tue Nov 4 13:15:22 UTC 2025


On Thu, 30 Oct 2025 11:46:11 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 incrementally with three additional commits since the last revision:
> 
>  - Revert "Erase obsolete comments"
>    
>    This reverts commit 860b6ee6faeb6e56e292abef1c85faad456729e2.
>  - fix space
>  - Erase obsolete comments

Looks reasonable. A few questions/nits:

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

> 728:   // Assume ~3% of the .debug_aranges is DebugArangesSetHeader and the rest is made up of AddressDescriptors.
> 729:   const uintptr_t estimatedSetHeaderSize = _size_bytes / 32;
> 730:   const size_t initial_capacity = (_size_bytes - estimatedSetHeaderSize) / sizeof(AddressDescriptor);

Suggestion:

  const uintptr_t estimated_set_header_size = _size_bytes / 32;
  const size_t initial_capacity = (_size_bytes - estimated_set_header_size) / sizeof(AddressDescriptor);

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

> 929: bool DwarfFile::ArangesCache::add_entry(const AddressDescriptor& descriptor, uint32_t debug_info_offset) {
> 930:   if (_count >= _capacity && !grow()) {
> 931:     destroy(true);

Why it calls `destroy` here? Can you call destroy multiple times? I wonder if it would be cleaner to move `destroy` to caller, seeing how it already handles the similar failure.

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

PR Review: https://git.openjdk.org/jdk/pull/27337#pullrequestreview-3416394946
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2490465475
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2490464716


More information about the hotspot-dev mailing list