RFR: 8365256: RelocIterator should use indexes instead of pointers

[Boris Ulasevich]

On Thu, 31 Jul 2025 06:17:24 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This PR replaces the `current` and `end` pointers with a `base` pointer alongside a `current` index and a `len`. This allows us to have `-1` as the initial value for current, while retaining `nullptr` as the 'dead' value for `_mutable_data`.
> 
> Performance testing shows no difference/performance improvements on DaCapo Linux x64. I don't think that these are actual improvements, but at least there are no clear regressions.
> 
> Testing: GHA

That is interesting. Thanks!

Is this change intended to resolve JDK-8361382 (NMT header corruption)? If so, please link it in the PR description and describe how the new logic prevents that corruption.

I remember that vnkozlov supports the blob_end() approach, so it’s best to wait for his input before changing it back to nullptr.

As for me, I agree that nullptr is a better sentinel than blob_end(). We originally switched to blob_end() for _mutable_data to work around JDK-8352112 (UBSan error on null-pointer offset), but that led soon to the intermittent JDK-8361304 crash in CodeCache::aggregate. Restoring nullptr avoids those pitfalls.

Replacing the two-pointer scheme (_current/_end) with an index-based design (_base/_current/_len) simplifies the logic and removes the dummy-pointer workaround. However, since relocation iteration is on a performance-critical path, benchmarks should be run to ensure that the added integer field and array indexing introduce no measurable regression.

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

PR Comment: https://git.openjdk.org/jdk/pull/26569#issuecomment-3140527868