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

[Kerem Kat]

On Tue, 4 Nov 2025 13:09:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

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

If the cache cannot grow, it becomes unusable as we will not use a partial cache. So we destroy the cache and fall back to the linear scan for the dwarf file.

I am moving the `destroy` call into `ensure_cached` as all other destroy calls are in that method, thanks.

Destroying a cache multiple times is not an error, as the heap pointer in `ArangesCache::free` is checked for null.

On the other hand, when destroy is called, it is followed by a return in `DebugAranges::ensure_cached`. Did you have a particular scenario when `destroy` is called multiple times?

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

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