[jdk17] RFR: 8269230: C2: main loop in micro benchmark never executed
Vladimir Kozlov
kvn at openjdk.java.net
Tue Jun 29 23:52:58 UTC 2021
On Mon, 28 Jun 2021 08:20:17 GMT, Roland Westrelin <roland at openjdk.org> wrote:
> The benchmark loop is roughly:
>
> for (int i = 0; i < limit; i++) {
> if (!(i < max_jint && i > min_jint)) {
> uncommon_trap();
> }
> }
>
> which IfNode::fold_compares() tranforms to:
>
> for (int i = 0; i < limit; i++) {
> if (!(i - min_jint - 1 <u -2)) {
> uncommon_trap();
> }
> }
>
> Range elimination then adjusts loop limits so the unsigned comparison
> can be removed. The new limit is:
>
> min(limit, max(-2 + min_jint + 1, min_jint)) = min(limit, min_jint) = min_jint
>
> and the main loop is never executed.
>
> The logic that protects against overflows during range check
> elimination is what causes the main loop to never be executed. As a
> fix, I propose delaying IfNode::fold_compares() if the resulting test
> compares with a potential negative number which could then cause RC
> overflow code to trigger. I think that would preserve the most
> interesting cases for IfNode::fold_compares() when it comes to range
> check elimination:
>
> i >= 0 && i < array.length
I will test it and approve after that if everything (including performance) is good.
Okay. Maurizio and Paul explained to me in the bug report that it is very important code pattern in foreign memory API because C2 still does not support RCE over long index loops [8259609](https://bugs.openjdk.java.net/browse/JDK-8259609).
Taking this into account I think it is fine to push it into JDK 17 after testing which I will do.
-------------
PR: https://git.openjdk.java.net/jdk17/pull/156
More information about the hotspot-compiler-dev
mailing list