RFR: 8305898: Alternative self-forwarding mechanism [v7]

[Aleksey Shipilev]

On Thu, 11 May 2023 09:46:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> Now that I had my morning coffee, I do have a question about the contract here. Can we accidentally call `oop->forward_to(compaction_point)` when `oop == compaction_point` from the compaction code?
>> 
>> No, that doesn't seem to happen. In this case, the object doesn't get forwarded at all. If it would happen, it could and should be ignored, because it would result in extra stuff to be executed.
>> 
>>> I guess that would be innocuous for the thing we want to protect against: recording the _promotion failure_, rather than the self-forwarding itself. In other words, the fact that object is self-forwarded might not exactly mean it failed the promotion, might just be a lucky coincidence?
>> 
>> No, we want to protect against self-forwarding, because that would irrecoverably destroy the Klass* with compact headers.
>> 
>>> If so, maybe this whole thing should be `oopDesc::forward_failed()` or some such, and then let the code decide how to record it, either with self-forwarding address (legacy) or with this new bit.
>> 
>> Yes, I guess I could do that.
>
> Yeah, perhaps due to the self-forwarding contract with `forwardee`, this is not significantly cleaner. The encapsulation does not achieve much if we have the gaping hole from the other side of this abstraction. So the original `forward_to_self` is already good. Sorry for pushing in the wrong direction :)

My only left-over concern is that the assert might still fail when self-forwarding for non-promotion-failure reasons, but that might as well indicate a performance problem in GC code that should avoid self-forwardings on the common path to begin with.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13779#discussion_r1190920035