Skip to content

[MINOR][CORE] Simplify the next-page index computation in BytesToBytesMap.MapIterator - #58736

Open
david-mollitor-db wants to merge 1 commit into
apache:masterfrom
david-mollitor-db:b2b-advance-nextidx
Open

[MINOR][CORE] Simplify the next-page index computation in BytesToBytesMap.MapIterator#58736
david-mollitor-db wants to merge 1 commit into
apache:masterfrom
david-mollitor-db:b2b-advance-nextidx

Conversation

@david-mollitor-db

Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

MapIterator.advanceToNextPage() in BytesToBytesMap computed the next-page index as
int nextIdx = dataPages.indexOf(currentPage) + 1; and then decremented it (nextIdx--) inside a
conditional. This reuses the indexOf result and sets nextIdx once in an if/else so it can be
final:

final int idx = dataPages.indexOf(currentPage);
final int nextIdx;
if (destructive && idx >= 0) {
  dataPages.remove(idx);
  pageToFree = currentPage;
  nextIdx = idx;
} else {
  nextIdx = idx + 1;
}

Why are the changes needed?

Minor readability/consistency cleanup: nextIdx becomes final and is assigned exactly once per
branch instead of being mutated. idx >= 0 is equivalent to the previous currentPage != null
guard — whenever currentPage is non-null it is an element of dataPages (assigned from
dataPages.get(...) and only removed here), and indexOf(null) is -1. Reusing idx for
remove(idx) also avoids the redundant second linear scan that remove(Object) performs. No lock or
I/O behavior is changed.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

Existing BytesToBytesMapOnHeapSuite and BytesToBytesMapOffHeapSuite pass (34 tests, covering
destructive iteration, spill, reset, and free); checkstyle is clean.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Opus 4.8

This pull request and its description were written by Isaac.

…sMap.MapIterator

`MapIterator.advanceToNextPage()` computed the next page index as
`int nextIdx = dataPages.indexOf(currentPage) + 1;` and then decremented it inside a
conditional (`nextIdx--`). Reuse the `indexOf` result and set `nextIdx` once in an
`if`/`else` so it can be `final`:

    final int idx = dataPages.indexOf(currentPage);
    final int nextIdx;
    if (destructive && idx >= 0) {
      dataPages.remove(idx);
      pageToFree = currentPage;
      nextIdx = idx;
    } else {
      nextIdx = idx + 1;
    }

`idx >= 0` is equivalent to the previous `currentPage != null` guard (whenever
`currentPage` is non-null it is an element of `dataPages`, and `indexOf(null)` is `-1`),
and reusing `idx` for `remove(idx)` avoids the redundant second linear scan that
`remove(Object)` performs. Behavior is unchanged. No lock or I/O behavior is changed.

Generated-by: Claude Opus 4.8
Co-authored-by: Isaac <no-reply@databricks.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant