Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
2, Introduce Off-Heap Technology for Large Arrays
Introduce an optimized memory management for large
arrays in a region-based garbage collector. More
specifically, this is a new heap scheme and large
object organization (in-heap and off-heap), an
enhanced method for allocating large objects (proxy
objects), and an optimized technique of accessing
large arrays during runtime (JIT optimizations).
3, Updated PR Changes
4, enable xint by default
5, remove unneeded changes
6, updated changes
7, more updated changes
old update
1 Fix build flag related issues on Java 8
-Fix incomplete issue to replace J9VM_ENV_DATA64 with
J9VM_GC_ENABLE_SPARSE_HEAP_ALLOCATION
-Add/Enable buildflag gc_enableSparseHeapAllocation for
J9VM_GC_ENABLE_SPARSE_HEAP_ALLOCATION in axxon Java28 build
-update getDataPointerForContiguous() to handle
VirtualLargeObjectHeapEnabled case
2, Free the sparse region only once for all reserved leaf regions
- new bool field _sparseHeapAllocation in MM_HeapRegionDescriptorVLHGC
for identiying the first leaf region reserved for sparse heap
allocation (default = false).
- set the first leaf region reserved for sparse heap allocation = true
during getSparseAddressAndDecommitLeaves().
- doObjectInVirtualLargeObjectHeap only once (for the first reserved
leaf region) in MM_RootScanner::scanObjectsInVirtualLargeObjectHeap()
3, new Update from code reviewing
Fix retrieving pontential stale pointer in jniGetPrimitiveArrayCritical
Update to retrieve arrayObject after enterCriticalRegion() to avoid
copy/move collection happen just before enterCriticalRegion()
(enterCriticalRegion() would prevent copy/move collection before
exitCriticalRegion()), the copy/move collection might move the
arrayObject. then cause jniGetPrimitiveArrayCritical return stale data
pointer.
-replace isAddressWithinHeap() with
(NULL != regionManager->regionDescriptorForAddress()).
4, Update macros rJ9JAVAARRAYCONTIGUOUS_EA
Update Macro J9JAVAARRAYCONTIGUOUS_EA and J9JAVAARRAYCONTIGUOUS_EA_VM to
also check isVirtualLargeObjectHeapEnabled if isIndexableDataAddrPresent
== true to handle VirtualLargeObjectHeapDisabled case in Balanced GC(
release JIT to initialize IndexableDataAddr for
VirtualLargeObjectHeapDisabled case).
Limitation: ArrayletDoubleMapping would not work properly.
- new boolean isVirtualLargeObjectHeapEnabled in J9JavaVM
- new boolean isVirtualLargeObjectHeapEnabled in J9VMThread
5, Detect offheap option for unsafe header
reset vm.unsafeIndexableHeaderSize and
vm.isVirtualLargeObjectHeapEnabled for off-heap case.
6, remove double mapping
7, DDR fixes
and fix the issue in jniReleasePrimitiveArrayCritical
(for zero size array, do not copyBackArrayCritical(), because
doesn't copyArrayCritical() in jniGetPrimitiveArrayCritical() for
removing double-mapping change).
8, Update from code review
9, DDR Changes for Off-Heap
his change would not have any dependance on off-heap runtime changes,
and should handle old core file(before any off-heap changes introduced),
intermediate core file(XXgc:disableIndexableDualHeaderShape) and new
core file(XXgc:enableVirtualLargeObjectHeap or
XXgc:disableVirtualLargeObjectHeap) smoothly.
use gcExtensions.isVirtualLargeObjectHeapEnabled for identifying
if off heap is enabled or not.
verify the DataAddr via hasCorrectDataAddrPointer() if
isVirtualLargeObjectHeapEnabled.
use javaVM.isIndexableDataAddrPresent for identifying if there is
extra DataAddr field in the header of IndexableObject.
output DataAddr after size for IndexableObject if
isIndexableDataAddrPresent.
handle new structures
J9IndexableObjectWithDataAddressContiguous/Discontiguous
use arrayletObjectModel->_arrayletRangeBase/
_arrayletRangeTop to verify if the address in heap.
10, code review update
11, update 2 for code review
12, Cmake update for off-heap
new define J9VM_GC_SPARSE_HEAP_ALLOCATION for cmake build
13, Update Java8 build specs for off-heap
new define J9VM_GC_SPARSE_HEAP_ALLOCATION for the build specs
14, J9VM_GC_ENABLE_SPARSE_HEAP_ALLOCATION -->
J9VM_GC_SPARSE_HEAP_ALLOCATION
15, compiler update
J9VM_GC_ENABLE_SPARSE_HEAP_ALLOCATION --> J9VM_GC_SPARSE_HEAP_ALLOCATION
16, rollback
17, j9gc_objaccess_arrayObjectDataDisplacement
18, remove "--enable-OMR_GC_SPARSE_HEAP_ALLOCATION" in mk files
19, replace with
<#if uma.spec.flags.gc_sparseHeapAllocation.enabled>
--enable-OMR_GC_SPARSE_HEAP_ALLOCATION \
</#if>
in configure_common.mk.ftl
20, J9JAVAARRAYCONTIGUOUS_WITHOUT_DATAADDRESS_EA to
J9JAVAARRAYCONTIGUOUS_BASE_EA_VM
21, remove unrelated changes
22, update for match PR20648
(Extract copy/free arrayCritical code from StandardAccessBarrier)
23, updateSparseDataEntryAfterObjectHasMoved in
WriteOnceCompactFixupRoots
24, Update fixupArrayletLeafRegionContentsAndObjectLists
- This fixing up is specific for hybrid arraylets,
for off-heap array the fix-up has been done for contiguous array pass.
So we should skip it for offheap enabled. It's a correctness problem,
since we might be finding garbage references to scan.
Additionally, because the leaf regions are supposed to be left
decommited till the array dies, we are recommiting them too early.
25, fix JVM_CopySwapMemory crash issue for off-heap
The java caller has added Unsafe.arrayBaseOffset() to the offset.
need to remove it as GetPrimitiveArrayCritical returns a pointer to
the first element, need to replace
J9VMTHREAD_CONTIGUOUS_INDEXABLE_HEADER_SIZE()
with J9VMTHREAD_UNSAFE_INDEXABLE_HEADER_SIZE() for off-heap case.
26, Rollback JVM_CopySwapMemory changes
Change-Id: I2597c71ccf4c5fcc0f3aa3aea9f793e783a0a304
Signed-off-by: lhu <[email protected]>- Loading branch information
