On 10/01/2013 08:06 AM, Erik Joelsson wrote:
On 2013-10-01 15:05, David Holmes wrote:
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.
Those are the very tests I used, with guidance from the performance team.
Refworkload fully supports cold start measurement on all of our
supported platforms; though it's be a while since it's been used,
so there could be some bit rot with some of the setup details.
The issue with cold start is that it takes some system configuration
work to get the benchmarks working. The benchmarks can also be
a bit abusive to your disk drive (because of the numerous reboots
that will happen). So, I would not recommend running them on your
personal machines. Fortunately, the cold start setup is well documented
in refworkload.
Point your browser at the coldstart docs inside a refworkload
distribution or workspace:
file:///path/to/your/refworkload/docs/users_guide/coldstart/index.html
file:///path/to/your/refworkload/docs/users_guide/benchmarks/startup3/index.html
Brian
/Erik
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
