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

Compiler should only use verified interface types for optimization

    Details

    • Type: Enhancement
    • Status: Open
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: 6, 9, 10
    • Fix Version/s: tbd
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Understanding:
      Cause Known
    • CPU:
      generic
    • OS:
      generic

      Description

      When a JIT compiles bytecode verified by the VM, any classes it encounters are guaranteed to be type-safe in their usages. However, the VM verifier has never verified the use of interfaces at all, as noted recently in the discussion of 5041456.

      In the type system which controls the C2 parser and optimizer, unverified interfaces are freely mixed with verified classes. The result is that the code which makes decisions based on statically predicted reference types must always have a cutout which disables the decision if the type in question is an interface instead of a class. If such a cutout is missing, there will be a bug, but only in rare cases where a class is recompiled without an interface, and client classes continue to assume it has the interface.

      Our system has a more or less complete set of such cutouts, because we have fixed a number of historical bugs involving interface paradoxes. However, there may be remaining bugs in the system, and new code involving reference type checks will always be somewhat buggy until the proper interface cutouts are coded.

      One reason we do not perform certain optimizations, such as CHA on interfaces and recognition of unique implementors, is that the new code to do this would have to "undo" some of the interface cutouts, and would therefore be risky. C1 has one such optimization, at the cost of inserting a local 'instanceof' check guarding the optimized 'invokeinterface'. Such an optimization in C2 is best done by the type system, which is impossible as long as type system assertions about interfaces are untrustworthy.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jrose John Rose
                Reporter:
                jrose John Rose
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Imported:
                  Indexed: