JDK-6312651 : Compiler should only use verified interface types for optimization
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6,9,10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-08-18
  • Updated: 2022-12-12
  • Resolved: 2022-11-21
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 20
20 b25Fixed
Related Reports
Cloners :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
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.

Comments
Changeset: 45d1807a Author: Roland Westrelin <roland@openjdk.org> Date: 2022-11-21 08:47:42 +0000 URL: https://git.openjdk.org/jdk/commit/45d1807ad3248805f32b1b94b02ac368e0d6bcc0
21-11-2022

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10901 Date: 2022-10-28 12:29:15 +0000
28-10-2022

Review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-May/033803.html
19-08-2020

EVALUATION The cause of this problem is given in the Description.
26-10-2005

SUGGESTED FIX In agreement with the verifier, treat all interface types in signatures (method and field) as denoting java/lang/Object. Use interface types within the compiler to denote only types which have been locally verified. Local verification includes passing an instanceof, checkcast, or invokeinterface. After this, simplify the code by removing interface cutouts.
18-08-2005