Jarreorder and classlists
kellyohair at gmail.com
Mon Aug 19 15:57:20 UTC 2013
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.
On Aug 19, 2013, at 8:17 AM, Erik Joelsson wrote:
> 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.
More information about the build-dev