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

[Aleksey Shipilev]

On Wed, 10 May 2023 10:26:39 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/oops/oop.inline.hpp line 270:
>> 
>>> 268: // Used by scavengers
>>> 269: void oopDesc::forward_to(oop p) {
>>> 270:   assert(p != cast_to_oop(this) || !UseAltGCForwarding, "Must not be called with self-forwarding");
>> 
>> 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? 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?
>> 
>> 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.
>
>> 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 :)

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

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