Re: A question about the patching instruction order of CompiledIC::internal_set_ic_destination

[Denghui Dong]

Hi Roland,

Thanks for your explanation.

For CompiledIC::set_to_monomorphic and the callee is a compiled code, icstub is created when the context is not safe.

```
    bool safe = SafepointSynchronize::is_at_safepoint() ||
                (!is_in_transition_state() && (info.is_optimized() || static_bound || is_clean()));

```

If the call site is clean, the patching action directly occurs without creating an icstub. In this case, if we patch the call instruction first, it could cause the cache mismatched situation I mentioned in the first email



Thanks,
Denghui
------------------------------------------------------------------
From:Roland Westrelin <rwestrel at redhat.com>
Send Time:2022年2月17日(星期四) 16:43
To:董登辉(卓昂) <denghui.ddh at alibaba-inc.com>; hotspot-compiler-dev <hotspot-compiler-dev at openjdk.java.net>
Subject:Re: A question about the patching instruction order of CompiledIC::internal_set_ic_destination


> I have a question about the patching order in CompiledIC::internal_set_ic_destination.
>
> If I understand correctly, the current implementation patches the CALL instruction first and then the MOV instruction.
>
> My question is why don't patch the MOV instruction first?
>
> Suppose an inline cache is in the transition from Clean to Monomorphic state, and the CALL instruction is patched already, but
> the MOV instruction is not. If another thread executes to this call site, the guard of the callee UEP will be failed and forward to _ic_miss_blob.

My recollection of this (but I haven't looked in a while) is that when
the call site requires the mov and the call to be patched, which as
you're saying can't be done atomically, a new out of line buffer is
created (an icstub I think it's called) where the mov, call sequence is
inserted. Then the call in the nmethod is patched to jump to the
stub. This way there's no atomicity issue. Then on a safepoint, when
there's a guarantee that no thread executes the call site, the call site
in the nmethod is patched again but this time it's the ic stub content
that's moved into the nmethod. Then the icstub can be discarded and
there's no extra jump from the call site to the callee.

Roland.