P4
ZAddressOffsetMax is used to scale a few of our BitMap and GranuleMap data structures. ZAddressOffsetMax is initialised to an upper limit, prior to reserving the virtual address space for the heap. After the reservation, the largest address offset that can be encountered may be much lower.
I propose we scale ZAddressOffsetMax down after our heap reservation is complete, to the actual max value an zoffset_end is allowed to be.
Doing this gives us two benefits. Firstly the assertions and type checks will be stricter, and will exercise code paths that otherwise only occur when using a 16TB heap. Secondly we can reduce the size of the data structures which scale with ZAddressOffsetMax. (For most OSs the extra memory of these data structures do not really matter as they are not page'd in. But they are accounted for both on the OS, allocator and NMT layers).
The page table, uses ZIndexDistributor to iterate and distribute indices. The different strategies have different requirements on the alignment of the size of the range it distribute across. My proposed implementation simply aligns up the page table size to this alignment requirement. As it is the least intrusive change, at the cost of some larger data structure than strictly required. The alternative would be to extend ZIndexDistributor with support for any alignment on the range, or condition the use of the distributed indices based on if they are less than the size.
The data structures can also be larger than required if we fail to reserve the heap starting at our heap base. However this is a very rare occurrence, and while it would be nice to extend our asserts to check for a "ZAddressOffsetMin", I'll leave that for a future enhancement.
I propose we scale ZAddressOffsetMax down after our heap reservation is complete, to the actual max value an zoffset_end is allowed to be.
Doing this gives us two benefits. Firstly the assertions and type checks will be stricter, and will exercise code paths that otherwise only occur when using a 16TB heap. Secondly we can reduce the size of the data structures which scale with ZAddressOffsetMax. (For most OSs the extra memory of these data structures do not really matter as they are not page'd in. But they are accounted for both on the OS, allocator and NMT layers).
The page table, uses ZIndexDistributor to iterate and distribute indices. The different strategies have different requirements on the alignment of the size of the range it distribute across. My proposed implementation simply aligns up the page table size to this alignment requirement. As it is the least intrusive change, at the cost of some larger data structure than strictly required. The alternative would be to extend ZIndexDistributor with support for any alignment on the range, or condition the use of the distributed indices based on if they are less than the size.
The data structures can also be larger than required if we fail to reserve the heap starting at our heap base. However this is a very rare occurrence, and while it would be nice to extend our asserts to check for a "ZAddressOffsetMin", I'll leave that for a future enhancement.
- links to
-
Commit(master)
openjdk/jdk/1f10ffba
-
Review(master)
openjdk/jdk/23822