Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8138651

-XX:DisableIntrinsic matches intrinsics overly eagerly

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
      None
    • Subcomponent:
    • Resolved In Build:
      b92

      Backports

        Description

        DisableIntrinsic filtering code looks for the vmIntrinsic name in the comma-separated list:

          ccstr disable_intr = NULL;
          if ((DisableIntrinsic[0] != '\0' && strstr(DisableIntrinsic, vmIntrinsics::name_at(id)) != NULL) ||
              (!compilation_context.is_null() &&
               CompilerOracle::has_option_value(compilation_context, "DisableIntrinsic", disable_intr) &&
               strstr(disable_intr, vmIntrinsics::name_at(id)) != NULL)
          ) {
            tty->print_cr("Disabling intrinsic %s by DisableIntrinsic", vmIntrinsics::name_at(id));
            return true;
          }

        Which means that supplying -XX:DisableIntrinsic=_copyOfRange matches *both* _copyOf and _copyOfRange intrinsics. I think the code should actually look for the vmIntrinsic name to be followed with a comma or \0. It gets much worse when you are trying to disable some new intrinsic, e.g. _getCharStringU, and (Unsafe::)_getChar gets disabled along.

        Makes performance work more tedious than it should nominally be.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  zmajo Zoltan Majo (Inactive)
                  Reporter:
                  shade Aleksey Shipilev
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: