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.
|