Jarreorder and classlists

[David Holmes]

On 1/10/2013 8:30 PM, Erik Joelsson wrote:
> Hello again,
>
> I have now regenerated the classlists @b107 and run new comparisons. To
> me it looks like the differences are essentially non existant between
> new and old classlists and in the previous comparison we saw no
> difference between random order and old classlists.
>
> It's very possible that it has an impact on cold starts, as Staffan
> suggests, but we have no way (that I know of) of measuring that, and is
> that really a valid requirement if we can't measure it?

There are startup benchmarks as part of our internal benchmarking 
suites. They are what are used to measure this AFAIK.

David

> /Erik
>
> On 2013-08-20 03:54, David Holmes wrote:
>> Hi Erik,
>>
>> Adding in hotspot-runtime-dev.
>>
>> There is a lot of history here and I'm not sure who remembers all the
>> details - if anyone. There are existing open bugs to re-assess the
>> utility of the jarreorder (7032729) and to update the classlists
>> (8005688).
>>
>> David
>> ------
>>
>> On 20/08/2013 1: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
>