RFR: 8340602: C2: LoadNode::split_through_phi might exhaust nodes in case of base_is_phi

[Daohan Qu]

# Description 

[JDK-6934604](https://github.com/openjdk/jdk/commit/b4977e887a53c898b96a7d37a3bf94742c7cc194) introduces the flag `AggressiveUnboxing` in jdk8u, and [JDK-8217919](https://github.com/openjdk/jdk/commit/71759e3177fcd6926bb36a30a26f9f3976f2aae8) enables it by default in jdk13u.

But it seems that JDK-6934604 forgets to check duplicate `PhiNode` generated in the function `LoadNode::split_through_phi(PhaseGVN *phase)` (in `memnode.cpp`) in the case that `base` is phi but `mem` is not phi. More exactly, `LoadNode::Identity(PhaseTransform *phase)` doesn't search for `PhiNode` in the correct region in that case.

This might cause infinite split which is similar to the bugs fixed in [JDK-6673473](https://github.com/openjdk/jdk/commit/30dc0edfc877000c0ae20384f228b45ba82807b7) and [JDK-8038348](https://github.com/openjdk/jdk/commit/913622a64157c4c2ce496ecddf7a8c4315e1ff84). The infinite split results in "Out of nodes" and make the method "not compilable".

Since JDK-8217919 (in jdk13u), all the later versions of jdks are affected by this bug when the expected optimization pattern appears in the code. For example, the following three micro-benchmarks running with


make test \
  TEST="micro:org.openjdk.bench.java.util.stream.tasks.IntegerMax.Bulk.bulk_seq_inner micro:org.openjdk.bench.java.util.stream.tasks.IntegerMax.Lambda.bulk_seq_lambda micro:org.openjdk.bench.java.util.stream.tasks.IntegerMax.Lambda.bulk_seq_methodRef" \
  MICRO="FORK=1;WARMUP_ITER=2" \
  TEST_OPTS="VM_OPTIONS=-XX:+UseParallelGC"


 shows performance improvement after this PR applied. (`-XX:+UseParallelGC` is only for reproduce this bug, all the bms in the following table are run with this option.)

|benchmark (throughput, unit: ops/s)| jdk-before-this-patch | jdk-after-this-patch |
|---|---|---|
|org.openjdk.bench.java.util.stream.tasks.IntegerMax.Bulk.bulk_seq_inner | 26.452 ±(99.9%) 0.185 ops/s | 62.060 ±(99.9%) 0.878 ops/s |
|org.openjdk.bench.java.util.stream.tasks.IntegerMax.Lambda.bulk_seq_lambda | 26.922 ±(99.9%) 1.710 ops/s | 67.961 ±(99.9%) 0.850 ops/s |
|org.openjdk.bench.java.util.stream.tasks.IntegerMax.Lambda.bulk_seq_methodRef | 28.382 ±(99.9%) 1.021 ops/s | 67.998 ±(99.9%) 0.751 ops/s |

# Reproduction

Compiled and run the reduced test case `Test.java` in the appendix below using 


java -Xbatch -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:LogFile=comp.log -XX:+UseParallelGC Test


and you could find that `Test$Obj.calc` is tagged with `make_not_compilable` and see some output like 


<failure reason='Out of nodes' phase='compile'/>"


And when `-XX:+AbortVMOnCompilationFailure` is used, vm will crash.

# Solutions

You could set `AggressiveUnboxing` to `false` to disable this optimization thus bypassing this bug, but I'm not sure if it will cause other regressions since it has been set to `true` for several years.

This PR tries to fix this bug with minimal side effect.

# Tests
I have run the following tests locally, and only see the `vmTestbase/jit/misctests/fpustack/GraphApplet.java` failure due to `DISPLAY` unset, which seems to be unrelated to this patch.
- [x] `jtreg:test/hotspot/jtreg/compiler`
- [x] `jtreg:test/hotspot/jtreg/vmTestbase`


# Appendix

import java.util.Random;

public class Test {

  static class Obj {
    final Integer[] array;
    final int start;
    final int end;

    Integer max = Integer.MIN_VALUE;

    Obj(Integer[] array, int start, int end) {
      this.array = array;
      this.start = start;
      this.end = end;
    }

    Integer cmp(Integer i, Integer j) {
      return i > j ? i : j;
    }

    void calc() {
      int i = start;
      do {
        max = cmp(max, array[i]);
        i++;
      } while (i < end);
    }
  }

  static final int LEN = 2000;
  static final Integer[] a = new Integer[LEN];
  static {
    Random r = new Random(0x30052012);
    for (int i = 0; i < LEN; i++) {
      a[i] = new Integer(r.nextInt());
    }
  }

  public static void main (String[] args) {
    System.out.println("Start");
    Obj o = new Obj(a, 0, LEN);
    for (int i = 0; i < 1000; i++) {
      o.calc();
    }
    System.out.println(o.max);
  }
}

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

Commit messages:
 - Check duplicate split in case of base_is_phi

Changes: https://git.openjdk.org/jdk/pull/21134/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21134&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340602
  Stats: 100 lines in 3 files changed: 63 ins; 29 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21134/head:pull/21134

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