You should check with the Hotspot runtime team. I seem to recall this might have some connection to class data sharing (cds) in the VM.
I agree that we should toss it if it is not needed. I've always wondered if it was just a complication we did not need anymore. -kto On Aug 19, 2013, at 8:17 AM, Erik Joelsson 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
