JDK-8226198 : use of & instead of && in LibraryCallKit::arraycopy_restore_alloc_state
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-06-15
  • Updated: 2020-05-14
  • Resolved: 2019-06-18
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 13 JDK 14
11.0.8-oracleFixed 13 b26Fixed 14Fixed
Related Reports
Relates :  
JDK-8225783 - Incorrect use of binary operators on booleans in type.cpp
Description
Jc Beyler discovered this issue in the opto/library_call.cpp.

The fragment is:

JVMState* LibraryCallKit::arraycopy_restore_alloc_state(AllocateArrayNode* alloc, int& saved_reexecute_sp) {
  if (alloc != NULL) {
    ciMethod* trap_method = alloc->jvms()->method();
    int trap_bci = alloc->jvms()->bci();

    if (!C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_intrinsic) &
          !C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_null_check)) {
    . . .

It seems, the bitwise operator '&' is used instead of the logical operator '&&'.
Comments
jdk11 backport request I would like to have the patch in OpenJDK11 as well (for better parity with 11.0.8_oracle). The patch applies cleanly, see also Alekseys comment above.
12-05-2020
Note for 11u backporters. This patch applies cleanly to 11u, passes tier1, tier2, tier3 tests on Linux x86_64. It looks trivial for backports, yet there is no indication it is needed. If it is needed for cleaner context for some other backport, please reuse this comment for fix request.
03-02-2020
What was the problem with using & instead of && here? I am struggling to understand if there is any problem that justifies the priority (P3) and backports (to 13u, at least). If there is a problem, we can bring it to 11u and 8u too.
20-01-2020
Though initially triaged as P4 for JDK 14, based on the comments in the source code location, ease of fix - if (!C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_intrinsic) & !C->too_many_traps(trap_method, trap_bci, Deoptimization::Reason_null_check)) { // Make sure there's no store between the allocation and the // arraycopy otherwise visible side effects could be rexecuted // in case of deoptimization and cause incorrect execution. propose to increase priority to P3 (ILW = MMH = P3) and will request approval for pushing the fix JDK 13.
17-06-2019