JDK-8242357 : [JVMCI] Incorrect use of JVMCI_CHECK_ on return statement
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11.0.7-oracle,15
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-04-08
  • Updated: 2021-01-04
  • Resolved: 2020-04-20
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 11 JDK 15
11.0.8-oracleFixed 15 b20Fixed
Related Reports
Relates :  
JDK-8220623 - [JVMCI] Update JVMCI to support JVMCI based Compiler compiled into shared library
Description
./share/jvmci/jvmciEnv.hpp

JVMCIObject create_string(Symbol* str, JVMCI_TRAPS) {
    return create_string(str->as_C_string(), JVMCI_CHECK_(JVMCIObject()));
  }

You can't use CHECK macros on a return statement - they expand to include code after the return and so have no affect.
Comments
11u downport Mark as jdk11u-jvmci-defer. The JVMCI_CHECK_ is currently missing in OpenJDK11 . Given the many missing JVMCI changes I skip this one.
18-05-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/1783b322df29 User: kvn Date: 2020-04-20 20:14:33 +0000
20-04-2020
src/hotspot/share/jvmci/jvmciEnv.hpp @@ -262,7 +262,8 @@ char* as_utf8_string(JVMCIObject str, char* buf, int buflen); JVMCIObject create_string(Symbol* str, JVMCI_TRAPS) { - return create_string(str->as_C_string(), JVMCI_CHECK_(JVMCIObject())); + JVMCIObject s = create_string(str->as_C_string(), JVMCI_CHECK_(JVMCIObject())); + return s; } JVMCIObject create_string(const char* str, JVMCI_TRAPS);
17-04-2020
Upstream JVMCI also has this issue and needs to be fixed: https://github.com/graalvm/graal-jvmci-8/blob/master/src/share/vm/jvmci/jvmciEnv.hpp#L263
17-04-2020
Did few more experiments with these macros and also tried to track usage in Eclipse. But no new results - it seems C++ still can't parse macros to find issues. So I will go with just this one case fix.
17-04-2020
The first time I ran into one of these with regular CHECK macro I was astounded the code after the return didn't generate any kind of warning/error. :(
17-04-2020
I ran on MacOS (clang) with -Wunreachable-code-aggressive and it showed a lot of "innocent" cases which can be ignored but it did NOT catch this case! And I did not find with grep any other cases.
17-04-2020
I spotted it when examining JVMCI_CHECK usages for Leo's NULL/NULLWORD changes. I used a simple grep for "return" and JVMCI_CHECK on the same line - so not guaranteed to catch all occurrences.
17-04-2020
[~dholmes] how you found this? I want to check other places.
16-04-2020