Replay compilation does not account for custom class loaders


The replay compilation system does not have a way of handling custom class loaders. Its notion of class identity is oblivious to class loaders. Consequently it fails to work properly with eclipse, which makes extensive use of class loaders. The profile run will generate class names with embedded class loader identities (more or less hashes). At replay time, these identities are not meaningful. The right solution may be to canonicalize the class loader identities in a way that can be matched between profile and replay time.




Steve Blackburn
June 1, 2010, 1:10 AM

The problem becomes critical with DaCapo 9.12, which loads all benchmarks reflectively.

Daniel Frampton has suggested that if we're lucky that particular case may be resolved by implementing the toString() method in the DaCapo classloader.

Steve Blackburn
December 21, 2011, 1:23 AM

I have done a major overhaul of replay compilation, committed in r10404.

Merged the ideas of "precompile" with replay compile. Both use the same framework, both compile in bulk.

Replay compilation is now explicitly triggered via a call to org.jikesrvm.adaptive.recompilation.BulkCompile.compileAllMethods(), typically from a benchmark harness, where it can be triggered at the end of the first iteration of the benchmark.

The classloading issue is addressed pragmatically by searching through a list of all classloaders for ones that could load the nominated class if the specified classloader is not found (this happens routinely when anonymous user-defined classloaders are used). In practice this works well. All DaCapo, jvm98 and jbb benchmarks that the regular system can run now work.

I introduced a replay verbosity flag (-X:aos:bulk_compilation_verbosity) so the user has a better idea of what replay is doing.

I updated the online documentation to reflect these changes.


Steve Blackburn


Steve Blackburn



Fix versions