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