RFR: 8305896: Alternative full GC forwarding [v29]
Roman Kennke
rkennke at openjdk.org
Thu May 4 16:46:37 UTC 2023
On Thu, 4 May 2023 13:04:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Add usual header include guards
>
> src/hotspot/share/gc/shared/slidingForwarding.cpp line 35:
>
>> 33: // We cannot use 0, because that may already be a valid base address in zero-based heaps.
>> 34: // 0x1 is safe because heap base addresses must be aligned by much larger alignment
>> 35: HeapWord* const SlidingForwarding::UNUSED_BASE = reinterpret_cast<HeapWord*>(0x1);
>
> I try to understand under which circumstances a zero heap location would be okay. This is *uncompressed* oops, right?
>
> If that were 0, you could just hardcode constexpr 0 in the header.
When running with compressed oops, the heap may be allocated at the zero page, iirc. Yes, this would still be using sliding-forwarding. (*Actually* this may be an optimization opportunity: When JVM runs with compressed oops, we could simply use compressed oops in the forwarding ptr and avoid the whole sliding-forwarding stuff. Maybe as a follow-up?)
> src/hotspot/share/gc/shared/slidingForwarding.cpp line 111:
>
>> 109: _table[i]._from = nullptr;
>> 110: _table[i]._to = nullptr;
>> 111: }
>
> It would be enough to set _from to nullptr.
Yes but I like this to be clean. ;-)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1185262678
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1185263534
More information about the shenandoah-dev
mailing list