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

Kerem Kat krk at openjdk.org
Fri Oct 24 13:28:06 UTC 2025


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

Benchmark of `PrintAssembly` before/after PR, on a noisy intel laptop:


Benchmark 1: /ws/jdk/build/linux-x86_64-server-release/jdk-nocache/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly
  Time (mean ± σ):     907.2 ms ± 118.1 ms    [User: 640.1 ms, System: 479.6 ms]
  Range (min … max):   561.6 ms … 1232.0 ms    100 runs


Warning: Ignoring non-zero exit code.
Benchmark 2: /ws/jdk/build/linux-x86_64-server-release/jdk-cache/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly
  Time (mean ± σ):     820.5 ms ±  51.7 ms    [User: 571.2 ms, System: 433.6 ms]
  Range (min … max):   615.9 ms … 1003.5 ms    100 runs


With the new cache, PrintAssembly of just `java` command is ~80ms (~%11) faster, over 100 runs each.

Looking into the `TestDwarf` for benchmarking next.

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

PR Comment: https://git.openjdk.org/jdk/pull/27337#issuecomment-3443150589


More information about the hotspot-dev mailing list