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

[mmyxym]

On Mon, 24 Jul 2023 10:36:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 210:
>> 
>>> 208:   markWord m = obj->mark();
>>> 209:   if (m.is_marked()) {
>>> 210:     obj = obj->forwardee(m);
>> 
>> Shall we have a method "oop::forwardee_not_self" which guarantee to be not self fowarded? So we can remove the self-forward if-check in GC critical path.
>
> Are there any paths that don't need to handle self-forwarded state?
> 
> Also, it seems to me that the path would be dominated by the load of the mark-word. Testing-and-branching for the self-forwarded bit seems like the minor problem there. It would be nice if we could tell the C++ compiler that the branch is expected to be uncommon, so it could shape the emitted code accordingly, but, afaik, we can't.
> 
> If we were to micro-optimize the forwarding-decoding, then it would be more useful to optimize the common pattern:
> 
> 
> if (o->is_forwarded()) { // Loads and tests the mark-word
>   oop fwd = o->forwardee(); // Loads mark-word again, and decode forwardee.
>  ...
> }
> 
> 
> To something like:
> 
> 
> oop fwd = o->forwardee(); // Return nullptr when not forwarded
> if (fwd != nullptr) {
>   ...
> }
> 
> 
> There's a way to improve further on this, as I proposed back in the early versions of #5955, which also avoids the decoding altogether if not forwarded, but it's a little more clunky:
> 
> 
> OopForwarding fwd(obj);
> if (fwd.is_forwarded()) {
>   oop forwardee = fwd.forwardee();
>   ...
> }
> 
> 
> where the scoped OopForwarding object would encapsulate the markWord and the testing and decoding of the fwd-ptr, but it has been rejected back then. But it would certainly help more than an oopDesc::forwardee_not_self() approach (if that were even possible, which I think it is not).

Sorry. It's my misunderstanding. G1ParScanThreadState::do_oop_evac still needs to handle self forward.

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

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