Alan,
This fix looks good and the "## fast path ..." comment can be taken out
as Chris pointed out.
A minor note - the list of known jar files seems to be incomplete (e.g.
tzdb.jar and some windows-specific ones). I think it may be better to
file a bug to follow up this and maybe even better to replace the
hardcoded list with other mechanism (if appropriate).
Mandy
On 2/21/2013 6:33 AM, Alan Bateman wrote:
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 previously.
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.
http://cr.openjdk.java.net/~alanb/8008290/webrev/
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.
Thanks,
Alan.
