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

Make bimorphic inlining possible with -XX:+AlwaysIncrementalInline

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Unresolved
    • Icon: P4 P4
    • tbd
    • 20
    • hotspot

      In JDK-8293798, we had to disable -XX:+AlwaysIncrementalInline in a test that expected bimorphic inlining. Unfortunately, with the flag enabled we produce two LateInlineCallGenerator, which have is_inline false - hence we decide not to do bimporphic inlining. Instead we have one static call (usually gets inlined), and a virtual call for the other class.

      The PR describes the issue in more detail: https://github.com/openjdk/jdk/pull/10310

      According to [~vlivanov] and [~thartmann] the flag -XX:-AlwaysIncrementalInline has been usefull for debugging and testing late inlining, so we should keep the flag. And it would be nice to have the bimorphic inlining decision consistent with and without the flag enabled.

      The problem is this: we decide if we do bimorphic inlining at parse time. Usually we can already decide if we do inlining at this point - but with -XX:+AlwaysIncrementalInline we only decide much later. So we somehow must decide if we want the bimorphic case without knowing about the inlining component.

      A simple and optimistic approach is this: always do bimorphic case if we get two LateInlineCallGenerator. The logic is simple, but there may be more cases where we do not end up inlining both calls.
      A more pessimistic approach: get the "normal" call generator we we would have without -XX:-AlwaysIncrementalInline , ask that one if it wants to inline, as a heuristic if the LateInlineCallGenerator will eventually inline - and to keep the decision consistent with the case where we do not have -XX:-AlwaysIncrementalInline . The code will be a bit more complex in this case though, I suspect.

      [~kvn] would like consistency, [~vlivanov] considers it as nice but not required. [~thartmann] asked me to write up this RFE so we keep track of this issue, but for now we do not target it.

            epeter Emanuel Peter
            epeter Emanuel Peter
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: