8008290: (profiles) Startup regression due to additional checking of JAR file manifests

[Mandy Chung]

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.