Jarreorder and classlists

[Staffan Larsen]

We did have something similar in JRockit. In that case it was designed to increase start up performance. If I remember correctly it only gave measurable performance in a _cold_ start - that is when the jar file was not already present in the HD cache but had to be read from spinning rust. That may not be a relevant case any more.

/Staffan

On 19 aug 2013, at 17:17, Erik Joelsson <erik.joelsson at oracle.com> wrote:

> Hello,
> 
> I wonder if anyone knows more about the jarreorder tool and why we use it?
> 
> As I understand it, we have precalculated classlists for each platform (most likely outdated) and the tool is used to make sure those classes end up in a specific order, last in rt.jar. I assume this is some kind of startup time optimization.
> 
> I got some help from Claes in the performance team and did a quick run of a startup and footprint benchmark, comparing a build with the rt.jar reordered as normal and one where I simply turned off this feature and let the files end up in the default order. Our preliminary findings show that any difference between the two is negligible. Before we declare it useless, we might need to test with freshly generated classlists? Does anyone know how to generate them? Is there some other benefit of this that I might have missed?
> 
> I would like to propose removing jarreorder to simplify the build. This would also enable faster incremental builds of the images target, by not having to rebuild the whole rt.jar every time.
> 
> /Erik