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

[C1, C2] Split inlining control flags

    Details

    • Subcomponent:
    • Resolved In Build:
      b24

      Description

      C1 and C2 JIT compilers are using the same global inlining control flags:
      MaxInlineSize
      MaxTrivialSize
      MaxInlineLevel
      MaxRecursiveInlineLevel

      There's a demand for tuning some of these settings (e.g. JDK-8234863). However, some settings may be good for C2, but bad for C1 or vice-versa.

      C2 rather benefits from more inlining while C1 has issues with that.
      C1 doesn't have the concept of uncommon traps so it compiles all paths. And it may have to use patching stubs if compiling paths which were never executed until compilation time.
      Inlining more methods with cold paths which contain lots of variables may increase stack space usage for C1 frames.

      A possibilty to discuss could be adding separate flags for C1:
      product(intx, C1MaxInlineSize, 35, "The maximum bytecode size of a method to be inlined by C1")
      product(intx, C1MaxTrivialSize, 6, "The maximum bytecode size of a trivial method to be inlined by C1")
      product(intx, C1MaxInlineLevel, 9, "The maximum number of nested calls that are inlined by C1")
      product(intx, C1MaxRecursiveInlineLevel, 1, "maximum number of nested recursive calls that are inlined by C1")

      In addition to that, it may make sense to limit stack frame size impact for inlining decisions for C1 (by a new flag, e.g. called C1InlineStackLimit) and tuning C1 differently.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                mdoerr Martin Doerr
                Reporter:
                mdoerr Martin Doerr
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: