8008290: (profiles) Startup regression due to additional checking of JAR file manifests
Alan.Bateman at oracle.com
Thu Feb 21 14:33:09 UTC 2013
This one is a startup-time regression caused by the compact profiles work.
As background, there was a lot of work done in the distant past on
startup performance. Amongst the startup improvements was to the code
that checks for the Class-Path attribute when opening JAR files so that
it skips checking of known JAR files (in the JDK) and in addition do a
quick search of the manifest to avoid parsing it when not present. These
optimizations were disrupted by the profiles work so the change here is
to fix this regression to get startup performance back to where it was
The changes are very simple, it just extends the implementation to check
for the Profile attribute in the same way that we've always checked the
Class-Path attribute. I've also refreshed the list of "known" JAR files
as that has been stale for some time. The changes do mean the manifest
bytes are searched twice and it might benefit from using a multi-pattern
search and that it something for another day. So far, at least in the
startup tests that I've run, it doesn't make any observable difference
and startup performance is back to where it was.
The webrev with the changes is here. I should point out that this is
against jdk8/build as the changes aren't in jdk8/tl at this time.
Finally, I should explain that the goal here is simply to get startup
back to where it was. There is clearly other clean-up that should be
done on this code at some point.
More information about the core-libs-dev