RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory

Axel Boldt-Christmas aboldtch at openjdk.org
Wed Oct 16 05:26:10 UTC 2024


On Tue, 15 Oct 2024 22:25:17 GMT, Kim Barrett <kbarrett 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.
>
> 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.

Checking and returning `*this` seems fine to me. Seems like the least surprising solution. 

The copy assignment operator is currently only ever used in a gtest.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21523#discussion_r1802370478


More information about the hotspot-gc-dev mailing list