Bug ID: JDK-8237949 CTW: C1 compilation fails with "too many stack slots used"

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 15
15 b20Fixed

$ cd test/hotspot/jtreg/testlibrary/ctw
$ make
$ cd dist
$ wget https://repo1.maven.org/maven2/com/sibvisions/jvx/jvxserver/2.8/jvxserver-2.6.jar
$ JAVA_OPTIONS="-XX:+AbortVMOnCompilationFailure" ./ctw.sh jvxserver-2.6.jar

#  Internal Error (/home/shade/trunks/jdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:2009), pid=20494, tid=20506
#  fatal error: Not compilable at tier 1: too many stack slots used
#
# JRE version: OpenJDK Runtime Environment (15.0) (fastdebug build 15-internal+0-adhoc.shade.jdk-jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 15-internal+0-adhoc.shade.jdk-jdk, mixed mode, sharing, tiered, compressed oops, shenandoah gc, linux-amd64)

C1:  53149 8766   !b  1       com.sibvisions.rad.server.Server::process (2630 bytes)


It blows this check in c1_LinearScan.cpp:

  // the class OopMapValue uses only 11 bits for storing the name of the
  // oop location. So a stack slot bigger than 2^11 leads to an overflow
  // that is not reported in product builds. Prevent this by checking the
  // spill slot here (altough this value and the later used location name
  // are slightly different)
  if (result > 2000) {
    bailout("too many stack slots used");
  }

However, the OopMapValue storage had been extended in JDK-8231586. This check might be relaxed, I think.

[~kvn] i missed this comment. for the reported case, it was compiling in level 1, when i increased the limit it went for compilation at next levels, making it to fail at level 3 later due to code buffer overflow.
27-04-2020
[~jcm] Do I understand correctly that when you changed check to 'if (result > 8000) {' you got other failures during C1 compilation? And with original check you don't see those failures?
17-04-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/51fa762ea38d User: jcm Date: 2020-04-16 17:02:40 +0000
16-04-2020
JDK-8231586 fixes truffle use-case, and is not applicable forJava. Even if i extend the range, it will bailout later due to various other reasons. So, decided to remove the misleading comment and close the case.
16-04-2020