JDK-4850474 : dependence information is inaccurate, leading to intermittent COMPILE FAILED
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: sparc
  • Submitted: 2003-04-18
  • Updated: 2005-09-22
  • Resolved: 2005-09-22
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.
6 b53Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Here's a smoking gun for the cleanup I've long wanted to do on the
jury-rigged data structure that pertains to nmethod::first_dependent.

If the compiler substitutes a unique concrete subclass B for a given
abstract class A, it will issue a dependency which mentions A (and
no method).  This dependency actually states that A must have no subclasses
at all, so as soon as it is examined, the method will fail to compile,
or will be deoptimized.  If, as happens in big-apps, there is concurrent
class loading happening, even if that concurrent class loading is unrealated
to the method in question, that method will be marked "COMPILE FAILED",
because the system dictionary's mod-tick will have incremented a bit,
and the check of the new dependency (on A) will fail (because of B).

Solution:  Have a real data structure for dependencies, with an enum
that distinguishes the separate types of dependency.

SUGGESTED FIX See PRT webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2005/20050908124746.jrose.mustang-dependencies/workspace/webrevs/webrev-2005.09.09/index.html

EVALUATION ###@###.### 2003-04-17 Fix needed. -----