RFR: 8287385: Suppress superficial unstable_if traps [v2]

[Xin Liu]

On Thu, 11 Aug 2022 02:31:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I would need to test performance with these changes. Did you ran any benchmarks yourself?

I ran Renaissance and SpecJBB. I didn't see regression. My understanding is that the concerning code shapes are not in hot paths in those benchmarks. 

You are right about this EA case! We only see one allocation in speculative compilation. If we consider both paths, we end up with a phi node to merge them. It can be addressed in this [effort](https://github.com/openjdk/jdk/pull/9073) 

Regarding to this idea, I am thinking about the debate between _predicable slow_ vs _unpredictable fast_. If we leave many runtime traps, we certainly maximize performance, but that is _unpredictable fast_. Essentially, we treat a method more like a trace rather than a CFG. If external conditions change, the program will have a performance hit and eventually go to _predicable slow_. Nowadays, micro-service architectures is popular and it's also very common that dozens of threads are sharing with a nmethod across multi-cores. The runtime trap is expensive and it may trigger a cascading failure. eg. A load-balancer will assign traffics to other servers when it realizes that the response time of a server is long. That behavior itself may cause a bigger problem. On the other side, _predictable slow_ isn't necessarily slow. We still can work on performance improvement.

This effort is extensible. Currently, we have to trigger an unstable_if trap for a counted loop whose trip count is big. it's because method data indicates that it's likely to take. if we considered the trivial block which only contain 'break', we would avoid that too.


do (int i=0; ; ++i) {
 ...
 //
 if (i < 1_000_000) goto header
 else break;
}

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

PR: https://git.openjdk.org/jdk/pull/9601