On 21/02/2013 16:11, Lance Andersen - Oracle wrote:
Alan,
the changes look good and glad you added the extra comments for clarity.
+1
Trivially, I think you can remove the comment:
* ## Add a fast path like Class-Path to avoid reading the manifest
when the attribute
* is not present.
-Chris.
Best
Lance
On Feb 21, 2013, at 9: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.
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
