JDK-6980862 : too aggressive compiler optimization causes stale results of Types.implementation()
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: unknown
  • Submitted: 2010-08-30
  • Updated: 2011-05-17
  • Resolved: 2011-05-17
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 7
7 b114Fixed
Related Reports
Relates :  
JDK-6337171 - javac should create bridge methods when type variable bounds restricted
Relates :  
JDK-6827648 - Extremely slow compilation time for visitor pattern code + generics
Description
The fix for 6827648 introduced a bug in Types.implementation(). The fix introduced a cache in order to store method implementations (this boosted javac implementation, as javac non longer had to scan the supertype hierarchy looking for suitable implementations of methods).

Unfortunately, as the scopes are further touched by javac code (e.g. in stages like Lower or TransTypes), the cache ends up containing stale values (e.g. because meanwhile, an additional implementation could have been added to a scope). While this problem has not been noticed, its impact is significant and it is actually holding back the fix for 6337171.
Comments
SUGGESTED FIX A webrev of this fix is available at the following URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/50f9ac2f4730
18-09-2010
EVALUATION Given a class hierarchy of the kind A1 extends A2 extends ... extends An the implementation of method m() in Am is a function of the members of Am, Am+1, Am+2 ... An-1, An. In other words, the scopes of all the subclasses of a class C (whose implementation is to be retrieved) uniquely determine the implementation of a method in C. This means that, should javac implement some caching mechanism in order to speed up implementation discovery, this mechanism should be made flexible so that, should any change occur to any of the subclasses' scopes, the cached implementations should all be flushed, as they potentially point to stale values.
30-08-2010