> This PR prevents a missed optimization caused by a breach of idempotence in
> `InlineTypeNode::Value` when handling contradicting method return profiles.
>
> ## Conflicting return profiles
>
> Suppose we have the following java code, and that we have record profile data
> for both callsites (`call(...)` and `callWrapper(...)`):
>
>
> static MyValue callWrapper(...) {
> return call(...); // callsite #1
> }
>
> public static MyValue test() {
> return callWrapper(...); // callsite #2
> }
>
>
> It could be that `test` is not the only place where we call
> `callWrapper(...)`, and that the other call sites result in wildy different
> executions of callsite `#1` with wildly different return values at that
> callsite.
>
> Suppose that callsite `#1` always returns `null`, except when `callWrapper`
> is called from callsite `#2` where it throws an exception. In
> `ciMethod::return_profiled_type`, we end up with the following
> `ProfilePtrKind`:
> - For callsite `#1`: `ProfileAlwaysNull`, because we have only observed
> `null` (the rest of the time an exception was thrown, so we didn't see
> anything)
> - For callsite `#2`: `ProfileNeverNull`, because we have never observed a
> return value and this is basically the default
>
> Please look at the test from this PR for a more complete example.
>
> These two profiles contradict each other. If we do incremental inlining
> (probably not limited to it, but easier to reproduce), we can easily end up
> in a situation where a speculative type derived from the return of the
> callsite is `NotNull` before inlining the outer callsite, and then moves to
> `ptr:null` after inlining. This can confuse `Value` implementations that rely
> on `filter_speculative`. This is handled gracefully for `ConstraintCastNode`,
> but not for `InlineTypeNode`.
>
> ## Missed optimization
>
> In `InlineTypeNode::Value`, we have:
> https://github.com/openjdk/valhalla/blob/e391f76e7db834f50c1a0af466daf95a65a79f23/src/hotspot/share/opto/inlinetypenode.cpp#L1619
>
> Suppose we have the following types (only the speculative part is shown):
>
> oop:
> instptr:compiler/valhalla/inlinetypes/TestPollutedCallsiteProfileInlineType$MyValue:NotNull:exact
> *,iid=bot (flat in array)
> _type:
> instptr:compiler/valhalla/inlinetypes/TestPollutedCallsiteProfileInlineType$MyValue:NotNull:exact
> *,iid=bot (flat in array)
>
>
> After this step we have `t = oop = _type`.
>
> The oop input suddenly changes types because of incremental inlining, as
> explained in the previous section. It goes from `NotNull` to `ptr:null`
> because the type from the polluted profile pr...
Benoît Maillard has updated the pull request incrementally with one additional
commit since the last revision:
Reduce test iterations
-------------
Changes:
- all: https://git.openjdk.org/valhalla/pull/2351/files
- new: https://git.openjdk.org/valhalla/pull/2351/files/3861bad5..699bf5cc
Webrevs:
- full: https://webrevs.openjdk.org/?repo=valhalla&pr=2351&range=01
- incr: https://webrevs.openjdk.org/?repo=valhalla&pr=2351&range=00-01
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/valhalla/pull/2351.diff
Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2351/head:pull/2351
PR: https://git.openjdk.org/valhalla/pull/2351
