RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
Kim Barrett
kbarrett at openjdk.org
Tue Oct 15 22:28:11 UTC 2024
On Tue, 15 Oct 2024 11:50:13 GMT, Joel Sikström <jsikstro at openjdk.org> wrote:
> ZPhysicalMemory stores a sorted array of physical memory segments. Segments are added using either add_segments or add_segment, where the former calls add_segment on each individual segment. add_segment inserts segments in address order and also merges segments when possible.
>
> When copying an instance of ZPhysicalMemory, segments are currently copied using either add_segments or add_segment, which works as described above. This requires more work than necessary and should be simplified to account for the fact that the array of segments is always sorted.
>
> When copying, the copy constructors should instead use append or appendAll from the underlying GrowableArrayCHeap and also reserve enough memory so that the array's capacity is not increased more times than necessary during copying.
>
> Tested with tiers 1-3.
Changes requested by kbarrett (Reviewer).
src/hotspot/share/gc/z/zPhysicalMemory.cpp line 58:
> 56:
> 57: const ZPhysicalMemory& ZPhysicalMemory::operator=(const ZPhysicalMemory& pmem) {
> 58: // Free and copy segments
pre-existing: Seems like this ought to be checking for self-assign. I'd be okay with asserting against, even
though that's often frowned on in various writings on the subject.
-------------
PR Review: https://git.openjdk.org/jdk/pull/21523#pullrequestreview-2370803309
PR Review Comment: https://git.openjdk.org/jdk/pull/21523#discussion_r1802084247
More information about the hotspot-gc-dev
mailing list