[lworld] RFR: 8367245: [lworld] C2 compilation fails with "Missed optimization opportunity in PhaseIterGVN"

[Roland Westrelin]

On Thu, 6 Nov 2025 11:15:11 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>>> Additionally, an empty speculative type is supposed to mean that the path is speculatively unreachable,
>> 
>> Or that profile data for 2 different points in the execution is inconsistent which given how profile data is collected seems as likely to me.
>> 
>> Speculative types were added as a mechanism to fight profile pollution for scripting languages running on the JVM (specifically nashorn). They work really well in some cases. But they also have limited applicability. To me, it doesn't seem like a good use of developer time or our complexity budget to go with a complicated fix.
>
>> I have looked at the example provided by @rwestrel , and it seems true that when the speculative type is empty, the node is speculatively unreachable (`test1` is always called with `flag1` being `false`, so the return type of `inline2(flag2)` inside the compilation of `test1` is unreachable). Now what can we do with this?
> 
> That's how I crafted the test to get conflicting profiles.
> 
> I also had to use `TypeProfileLevel=222` to enable some profile collection that's disabled by default. Most compilation wouldn't even see that many speculative types.
> 
> Another way to get conflicting profiles would be to make sure profile collection only happens when some particular value is returned and not when some other is returned. Profile collection doesn't start on first execution and stops as soon as a method is compiled by c2. So if a method is called very often, 1) initially returns some type and 2) then only later some other type, and if compilation with c2 happens between 1) and 2), then profile data only reports the type collected in 1).

> I'm trying to understand why `cleanup_speculative` is doing so. It seems to come from [JDK-8031755: Type speculation should be used to optimize explicit null checks](https://bugs.openjdk.org/browse/JDK-8031755). Maybe @rwestrel would remember something about it, but it has been quite a while since!

I don't remember the details but I think the rationale is that if we're seeing conflicting profile, there's a good chance profile data is inaccurate and we can as well ignore it.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3496666140