RFR(S): 8190375: Java Crash in JavaBug.formatPos(I)Ljava/lang/String

[Doerr, Martin]

Hi Roland,

we have just debugged the same problem. Your fix looks good. I've tested it with my very simple stand-alone test (see below).
Without your fix, we get an ArrayIndexOutOfBoundsException. With this fix, it runs correctly. Thanks for fixing.

Best regards,
Martin


TestLoopLimit.java:
// run with -Xbatch -XX:CompileCommand=dontinline,TestLoopLimit::write TestLoopLimit
public class TestLoopLimit{

    static byte[] bytes = new byte[4];
    static int idx = 0;

    static void write(byte b) {
        bytes[idx++] = b;
    }

    static void test_loop(int size) {
        for (int align = size % 4; align != 0 && align != 4; align++) {
            write((byte)'-');
        }
    }


    static final int loop_cnt = 10000;

    public static void main(String args[]){
        for (int x = 0; x < loop_cnt; x++) {
            idx = 0;
            test_loop(x);
        }
        System.out.println("Test passed. Final idx: " + idx);
    }
}


-----Original Message-----
From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Tobias Hartmann
Sent: Montag, 13. November 2017 17:50
To: Roland Westrelin <rwestrel at redhat.com>; hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR(S): 8190375: Java Crash in JavaBug.formatPos(I)Ljava/lang/String

Hi Roland,

looks good to me!

I'm running some pre-integration testing.

Best regards,
Tobias

On 08.11.2017 10:05, Roland Westrelin wrote:
> 
> http://cr.openjdk.java.net/~roland/8190375/webrev.00/
> 
> Bounds of a counted loop iv can't be reliably determined from the
> init/limit bounds if the exit condition is "not
> equal". TestCountedLoopBadIVRange.test1() is an example of that. On
> first execution of the inner loop the loop runs from j = 0 to j = 4 but
> on second execution, j = 10 on entry so exit condition j != 5 never
> triggers and the test in the loop is the one that exits the
> loop. Current logic sets j to be in [0, 10[ which is incorrect.
> 
> The fix simply skips the logic that set the value of the Phi iv if the
> exit condition is "not equal". If init < limit for instance, the existing logic
> is correct but in that case, when the counted loop is created, the exit
> test is changed to a greater or less than test.
> 
> Roland.
>