IGNITE-28436 Introduce PartitionPageMemory for further reuse

[ibessonov]

https://issues.apache.org/jira/browse/IGNITE-28436

Thank you for submitting the pull request.

To streamline the review process of the patch and ensure better code quality
we ask both an author and a reviewer to verify the following:

The Review Checklist

• Formal criteria: TC status, codestyle, mandatory documentation. Also make sure to complete the following:
  - There is a single JIRA ticket related to the pull request.
  - The web-link to the pull request is attached to the JIRA ticket.
  - The JIRA ticket has the Patch Available state.
  - The description of the JIRA ticket explains WHAT was made, WHY and HOW.
  - The pull request title is treated as the final commit message. The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
• Design: new code conforms with the design principles of the components it is added to.
• Patch quality: patch cannot be split into smaller pieces, its size must be reasonable.
• Code quality: code is clean and readable, necessary developer documentation is added if needed.
• Tests code quality: test set covers positive/negative scenarios, happy/edge cases. Tests are effective in terms of execution time and resources.

Notes

• Apache Ignite Coding Guidelines

[Copilot]

Pull request overview

Introduces PartitionPageMemory as a partition-scoped page memory facade and migrates storage/index/page-memory components to consume it instead of the broader PageMemory, improving reuse and better expressing partition affinity.

Changes:

• Added PartitionPageMemory abstraction and delegate implementations for persistent and volatile page memory.
• Refactored page-memory-backed storages/trees (MV, indexes, free list, page handlers) to accept PartitionPageMemory.
• Updated tests and benchmarks to create and use per-partition page memory instances.

Reviewed changes

Copilot reviewed 47 out of 47 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
modules/storage-page-memory/src/test/java/org/apache/ignite/internal/storage/pagememory/mv/BlobStorageTest.java	Tests now use a spied PartitionPageMemory and stop page memory in @AfterEach.
modules/storage-page-memory/src/test/java/org/apache/ignite/internal/storage/pagememory/benchmarks/SortedIndexTreeInsertBenchmark.java	Benchmark passes PartitionPageMemory into SortedIndexTree and uses it for allocations.
modules/storage-page-memory/src/test/java/org/apache/ignite/internal/storage/pagememory/PersistentPageMemoryNoLoadTest.java	Tests now create dirty pages via PartitionPageMemory and adjust acquire/lock calls.
modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/mv/gc/GcQueue.java	GcQueue now accepts PartitionPageMemory.
modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/mv/VolatilePageMemoryMvPartitionStorage.java	Storage now receives PartitionPageMemory and threads it through renewable state updates.
modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/mv/VersionChainTree.java	VersionChainTree now accepts PartitionPageMemory.
modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/mv/RenewablePartitionStorageState.java	Stores a partition-scoped DataPageReader built from PartitionPageMemory.
modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/mv/PersistentPageMemoryMvPartitionStorage.java	Uses PartitionPageMemory for BlobStorage and for row-version traversal via renewable state.
modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/mv/IndexStorageFactory.java	Keeps and uses a PartitionPageMemory for meta-page allocation and index tree creation.
modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/mv/BlobStorage.java	BlobStorage now accepts PartitionPageMemory.
modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/mv/AbstractPageMemoryMvPartitionStorage.java	Removes per-storage DataPageReader; uses renewable state's reader instead, and updates state with PartitionPageMemory.
modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/index/sorted/SortedIndexTree.java	SortedIndexTree now accepts PartitionPageMemory.
modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/index/meta/IndexMetaTree.java	IndexMetaTree now accepts PartitionPageMemory.
modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/index/hash/HashIndexTree.java	HashIndexTree now accepts PartitionPageMemory.
modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/VolatilePageMemoryTableStorage.java	Creates a PartitionPageMemory once per partition and shares it across created trees/storages.
modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/VolatilePageMemoryDataRegion.java	Free list is created with a PartitionPageMemory facade.
modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/PersistentPageMemoryTableStorage.java	Creates PartitionPageMemory and passes it through free-list/trees/gc queue creation.
modules/page-memory/src/testFixtures/java/org/apache/ignite/internal/pagememory/benchmark/VolatilePageMemoryBenchmarkBase.java	Benchmark fixtures now build FreeListImpl using PartitionPageMemory.
modules/page-memory/src/testFixtures/java/org/apache/ignite/internal/pagememory/benchmark/PersistentPageMemoryBenchmarkBase.java	Stores per-partition PartitionPageMemory in a concurrent map for benchmarks.
modules/page-memory/src/testFixtures/java/org/apache/ignite/internal/pagememory/AbstractPageMemoryNoLoadSelfTest.java	No-load tests now operate via PartitionPageMemory while stopping the owner PageMemory.
modules/page-memory/src/test/java/org/apache/ignite/internal/pagememory/persistence/throttling/PageMemoryThrottlingTest.java	Tests now allocate/acquire/lock via PartitionPageMemory, using the new writeLockForce.
modules/page-memory/src/test/java/org/apache/ignite/internal/pagememory/persistence/replacement/AbstractPageReplacementTest.java	Replacement tests now use PartitionPageMemory for page operations/allocations.
modules/page-memory/src/test/java/org/apache/ignite/internal/pagememory/inmemory/VolatilePageMemoryNoLoadSelfTest.java	Volatile no-load tests allocate via PartitionPageMemory.
modules/page-memory/src/test/java/org/apache/ignite/internal/pagememory/freelist/FreeListImplTest.java	Free list tests now create and pass PartitionPageMemory.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/util/PageHandler.java	PageHandler helpers now accept PartitionPageMemory.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/tree/BplusTree.java	B+Tree constructors now accept PartitionPageMemory.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/persistence/PersistentPageMemory.java	Adds createPartitionPageMemory and internalizes previously PageMemory-interface methods.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/persistence/PartitionPageMemoryDelegate.java	New: persistent implementation of PartitionPageMemory via delegation.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/io/DataPageIo.java	Uses wrapPointer directly as pageBuffer moved off PageMemory; accepts PartitionPageMemory.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/inmemory/VolatilePageMemoryDelegate.java	New: volatile implementation of PartitionPageMemory via delegation.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/inmemory/VolatilePageMemory.java	Adds createPartitionPageMemory and internalizes low-level page ops used by the delegate.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/freelist/PagesList.java	PagesList now accepts PartitionPageMemory.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/freelist/FreeListImpl.java	FreeListImpl now accepts PartitionPageMemory.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/datastructure/DataStructure.java	Base datastructure now stores PartitionPageMemory.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/datapage/NonFragmentableDataPageReader.java	Reader now depends on PartitionPageMemory.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/datapage/DataPageReader.java	Reader now depends on PartitionPageMemory.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/PartitionPageMemory.java	New: partition-scoped page memory abstraction.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/PageSupport.java	Adds writeLockForce and removes isDirty.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/PageMemory.java	Becomes a factory/owner (no longer extends PageSupport/PageIdAllocator), adds createPartitionPageMemory.
modules/page-memory/src/main/java/org/apache/ignite/internal/pagememory/PageIdAllocator.java	Adds TODO documenting upcoming removal of groupId params.
modules/page-memory/src/jmh/java/org/apache/ignite/internal/pagememory/benchmark/PageReplacementBenchmark.java	Tracks per-page PartitionPageMemory to avoid acquiring/releasing via the global PersistentPageMemory.
modules/page-memory/src/integrationTest/java/org/apache/ignite/internal/pagememory/tree/persistence/ItBplusTreePersistentPageMemoryTest.java	Integration tests now pass PartitionPageMemory to reuse list creation.
modules/page-memory/src/integrationTest/java/org/apache/ignite/internal/pagememory/tree/inmemory/ItBplusTreeVolatilePageMemoryTest.java	Integration tests now pass PartitionPageMemory to reuse list creation.
modules/page-memory/src/integrationTest/java/org/apache/ignite/internal/pagememory/tree/inmemory/ItBplusTreeFakeReuseVolatilePageMemoryTest.java	Integration tests now pass PartitionPageMemory to fake reuse implementation.
modules/page-memory/src/integrationTest/java/org/apache/ignite/internal/pagememory/tree/ItBplusTreeReplaceRemoveRaceTest.java	Creates and uses PartitionPageMemory in concurrent replace/remove race test.
modules/page-memory/src/integrationTest/java/org/apache/ignite/internal/pagememory/tree/AbstractBplusTreeReusePageMemoryTest.java	Reuse tests accept PartitionPageMemory for reuse list creation.
modules/page-memory/src/integrationTest/java/org/apache/ignite/internal/pagememory/tree/AbstractBplusTreePageMemoryTest.java	Base B+Tree tests create PartitionPageMemory once and route allocations through it.

Comments suppressed due to low confidence (2)

modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/mv/BlobStorage.java:1

• PartitionPageMemory already conceptually binds a specific (groupId, partitionId), but BlobStorage still accepts and passes separate groupId/partitionId values to the DataStructure base. If these ever diverge, the structure metadata and the actual page operations can become inconsistent. Prefer deriving IDs from pageMemory.groupId()/partitionId() (or validate they match via assertions/argument checks) to prevent subtle misbinding bugs.
  modules/storage-page-memory/src/main/java/org/apache/ignite/internal/storage/pagememory/mv/RenewablePartitionStorageState.java:1
• RenewablePartitionStorageState is package-private, but this accessor is declared public, which unnecessarily widens the API surface. Consider making the method package-private (no modifier) to keep visibility consistent with the class and reduce accidental external coupling.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[tkalkirill]

From the ticket description it is not clear or obvious why the renaming is necessary.
Could you please add some motivation?

[ibessonov]

It's not a renaming, it's a new interface. Please read the description in the epic that covers this Jira: https://issues.apache.org/jira/browse/IGNITE-28429

[tkalkirill]

This looks very alarming and dangerous. I'm concerned about this issue; it's too dangerous to use in production.
What release is expected to fix it?

[ibessonov]

What is dangerous here? Could you please elaborate on your concerns? What should I fix?

[tkalkirill]

We discussed it in private messages. The problem itself is dangerous, and there's no information about a release that will fix it.

[ibessonov]

Thank you! Please let me clarify few points here:

• There's no danger here, it's not a functional bug, the issue doesn't block anyone from the production usages. All it gives us is temporary performance issues that go away shortly after a checkpoint is started.
• The problem cannot be fully fixed due to "stop the world" approach of a checkpoint process. All we can do it to minimize the pause. The same issue exists in Apache Ignite 2 in a more severe form, due to the way WAL works there.
• Page replacement issue, to my knowledge, does not exist in Apache Ignite 2 in this form, and I hope to address it in Apache Ignite 3 eventually as described in the aforementioned Epic.
• There is no information about release, because there's no deadline to this activity. It'll get released when it's finished, I can't say more.

@tkalkirill Are you planning to do a formal review of this PR, or was this just a single comment?

[ibessonov]

@tkalkirill Please reply. If the discussion is complete then please resolve your comment

[tkalkirill]

1. Overall, how much of a performance drop can this be? Could it cause a query to take a few seconds instead of a few milliseconds?
2. By how much will pauses be minimized? In numbers, percentages or parrots? PR about Ignite 3.0, I suggest not touching 2.0.
3. Great!
4. This is sad, I would like to see it in 3.2.

I'll try to do it within a couple of working days, if it doesn't happen by Tuesday, consider it just a comment.

[ibessonov]

1. It can cause a latency spike of up to several hundreds of milliseconds. In worst cases, on the largest of storage profiles, it can take longer.

2. I have no plans to reduce the time it takes for free-list cache to be flushed while holding a checkpoint write lock, at least for now. So, I expect there to be no other overhead besides that (and a write lock usage overhead itself). The sorting phase (those several hundreds milliseconds) will not affect the latency anymore.
There was no discussion of changes in Apache Ignite 2 here. That codebase has a rather different architecture, and other types of optimizations would fit better into it. Not even mentioning the complexities of a similar refactoring, it would have been a very complicated task. You can do that yourself if you like.

4. You can always contribute, right now this particular work is driven by me alone in my free time.