RFR: 8283422: Create a new test for JDK-8254790

[Tobias Hartmann]

On Mon, 21 Mar 2022 03:34:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The [JDK-8254790](https://bugs.openjdk.java.net/browse/JDK-8254790) initially was reported on macOS.
> It was found by the "javax/xml/crypto/dsig/GenerationTests.java" test which for some reason worked fine on Linux/Windows most? of the time.
> 
> I tried to run that test on Linux/Windows many times on a few systems and it always pass. Also, I got the same result for the tier1...tier4 tests.
> 
> I have found that the easiest way to reproduce the crash is to pass the result of the string.indexOf to the str.charAt when the heap is big enough. The test below[1] trigger the crash 1000 time in a row on win/lin on systems I have tested.
> 
> I am not sure what is the best way to contribute to the test, should I create a stand-alone test like[1], or update an existing test as I did for the first version of this PR?
> 
> [1]:
> 
> package compiler.intrinsics.string;
> 
> import static jdk.test.lib.Asserts.assertTrue;
> 
> public final class TestStringIndexOfLargeHeap {
>     static final int[] data = new int[Integer.MAX_VALUE / 2];
>     public static void main(String[] args) throws Exception {
>         test('a');
>         test('\ubeef');
>     }
>     private static void test(char ch) {
>         String str = ("0123456789" + ch).repeat(100);
>         for (int i = 0; i < 1_000_000; ++i) {
>             assertTrue(ch == str.charAt(str.indexOf(ch)));
>         }
>     }
> }

I think the root cause is simply that there is not enough memory available to the VM to allocate such a large object. `MaxRAMPercentage` is set to 4 but the test could also be executed on a system with a small memory size. I think the test needs to be robust enough to account for all kinds of machines/settings.

Do you know why the issue is only reproducible with a large heap and only if the heap is filled?

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

PR: https://git.openjdk.java.net/jdk/pull/7883