WIP:Defragment reserved regions for off heap Step1 #21817
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
should we not update scanObjectsInVirtualLargeObjectHeap path to rely on the map, too? |
LinHu2016
changed the title
For off-heap enabled case, the Large size Array(larger than region size) will be allocated on sparse heap, but we still reserve leaf regions for preventing over usage on heap. Currently we have to allocate/reserve whole region for the remaining bytes(remainder of array size from region size), it potentially generate fragmentation on heap. first step: 1, Decouple spineObject with leaf regions for off-heap eanbled case. 2, find spineObjects via SparseDataTable in recycling leaf regions. Signed-off-by: lhu <linhu@ca.ibm.com>
amicic
reviewed
May 12, 2025
runtime/gc_base/RootScanner.cpp
Outdated
| doObjectInVirtualLargeObjectHeap(spineObject, NULL); | ||
| sparseDataEntry = (MM_SparseDataTableEntry *)hashTableNextDo(&walkState); | ||
| } | ||
| } else { |
There was a problem hiding this comment.
this whole method is offheap specific - the else case should not exist anymore
amicic
reviewed
May 12, 2025
| } | ||
| sparseDataEntry = (MM_SparseDataTableEntry *)hashTableNextDo(&walkState); | ||
| } | ||
| while ((arrayletLeafCount > 0) && (NULL != (region = regionIterator.nextRegion()))) { |
There was a problem hiding this comment.
Perhaps good for the first cut, but this should be more efficient. All arraylet regions should be connected into a list, so finding the regions to recycle would be immediate. A similar list is already created with addToArrayletLeafList, but there are multiple of them, and they are local to the array object. We just need one single list for the whole heap (possibly AllocationContext), but it has to be thread safe.
LinHu2016
force-pushed
the
defrag-offheap
branch
4 times, most recently
from
089ad39 to
57dda2a
Compare
LinHu2016
force-pushed
the
defrag-offheap
branch
2 times, most recently
from
3730241 to
736c92b
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For off-heap enabled case, the Large size Array(larger than region size) will be allocated on sparse heap, but we still reserve leaf regions for preventing over usage on heap. Currently we have to allocate/reserve whole region for the remaining bytes(remainder of array size from region size), it potentially generate fragmentation on heap.
first step:
1, Decouple spineObject with leaf regions for off-heap eanbled case.
2, find spineObjects via SparseDataTable in recycling leaf regions.
#depends on eclipse-omr/omr#7748