On Thu, 6 Nov 2025 11:15:11 GMT, Roland Westrelin <[email protected]> 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
