Class LoadCache provides a way of remembering super-classes and implemented interfaces previously checked by the Transformer when deciding whether to inject rule code. It is only relevant when overriding or interface rules are present because in those circumstances it is necessary to check for rules that apply to classes up the super/interface hierarchy without the option to use calls to Class.getSuper() or Class.getInterfaces().

The cache is supposed to improve performance as part of a two-step strategy. Firstly, search of the loaded class lists associated with a class's loader and its parent loaders avoids the need to load and parse an in-memory byte[] representation of the class. Secondly, a cache hit avoids repeated construction and traversal of the loaded lcass array. The two assumptions here are that creating and traversing the loaded class array is cheaper than loading and parsing the byte[] representation and that classes so located will be likely to be checked multiple time. Prior tests on older JVMs using JBoss EAP 5 startup as the test vehicle pointed to these assumptions being valid (JBoss EAP 5 was, at the time, one of the most load-intensive applications available). Retesting on a recent Tomcat and JBoss Widlfly (both of which do a great deal of intensive class loading) indicates that the first assumption is not justified, which renders the status of the second one rather moot.

The nett result is that performance will be improved by removing the LoadCache and instead always loading bytecode when identification of an implemented super or list of implemented interfaces is required. This choice may not be better when a small number of classes are loaded but in such circumstances the overall times involved will be small so they are unlikely to be noticeably worse. However, this choice is very likely to be noticeable better (of the order of a few seconds improvement in the worst case) for circumstances like Wildfly or Tomcat startup where the class loading rate is high and many classes are loaded.