is it time fully optimize long loops? (JDK-8223051)

Jorn Vernee jorn.vernee at oracle.com
Thu Apr 23 12:52:38 UTC 2020


Hi Roland,

Sorry, I'm just now seeing this.

I was using the following test to diagnose C2 loop predication:

public class Main {

     static final int SIZE = 1_000_000;

     final long bound_long;
     final int bound_int;

     public Main() {
         this.bound_long = SIZE;
         this.bound_int = SIZE;
     }

     public static void main(String[] args) {
System.out.println(ProcessHandle.current().pid());
         run();
     }

     public static void run() {
         Main m = new Main();
System.out.println("=========================================================================");
         for (int i = 0; i < 20_000; i++) {
             m.invoke();
         }
     }

     public int invoke() {
         int sum = 0;
         var bound = this.bound_int;
         for (int i = 0; i < SIZE; i++) {
             if (i >= bound) throw new IllegalStateException();
             sum +=  i;
         }
         return sum;
     }
}

Together with explicitly disabling the inlining of the 'invoke' method.

Switching between `var bound = this.bound_int` and `var bound = 
this.bound_long` you should see that the bound check in the `if` is 
being eliminated in the int case, but not in the long case.

After some debugging the switch point between the 2 cases seems to be in 
'IdealLoopTree::iteration_split_impl' when initializing `should_rce` 
[1], but ultimately this call seems to bottom out in 
'PhaseIdealLoop::is_scaled_iv_plus_offset' in loopTransform.cpp, which 
is checking the nodes involved for integer opcodes explicitly [2].

In the Panama code we are currently working around this by assuming the 
operands of the calculation fit into `int` in some cases, and then 
explicitly casting them to ints, which then enables the optimization 
[3]. But, as John says, this is not ideal.

HTH,
Jorn

[1] : 
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopTransform.cpp#L3308
[2] : 
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopTransform.cpp#L2402
[3] : 
https://github.com/openjdk/panama-foreign/blob/c8fc03351277f318f86d333f7fff1338fe17a247/src/java.base/share/classes/jdk/internal/access/foreign/MemoryAddressProxy.java#L50-L94

On 10/04/2020 09:38, Roland Westrelin wrote:
> Once the long loop is transformed to an int counted loop what are the
> optimizations that need to trigger reliably? In particular do we need
> range check elimination? Can you or someone from the panama project shar
> code samples that I can use to verify the long loop optimizes well?
>
> Roland.
>


More information about the hotspot-compiler-dev mailing list