Community
Participate
Working Groups
Build id: I20060413-0010 All JARs in the SDK are now signed. This is causing some expensive JAR verification to happen, induced by IniFileReader. I'm not sure yet where is the best place to fix this. Here is the stack trace that leads to the verification: URLJarFile(JarFile).maybeInstantiateVerifier() line: 315 URLJarFile(JarFile).getInputStream(ZipEntry) line: 423 JarURLConnection.getInputStream() line: 146 URL.openStream() line: 941 IniFileReader.load(URL, URL, URL) line: 317 IniFileReader.load() line: 138 AboutInfo.readFeatureInfo(String, String, String) line: 69 FeatureEntry.getProperty(String) line: 241 BundleGroupProperties.getWelcomePageUrl(IBundleGroup) line: 195 BundleGroupProperties.getWelcomePageUrl() line: 103 AboutInfo.getWelcomePageURL() line: 298 WorkbenchActionBuilder.hasWelcomePage(AboutInfo[]) line: 1528 WorkbenchActionBuilder.makeFeatureDependentActions(IWorkbenchWindow) line: 1485 WorkbenchActionBuilder.makeActions(IWorkbenchWindow) line: 1290 WorkbenchActionBuilder(ActionBarAdvisor).fillActionBars(int) line: 147 WorkbenchActionBuilder.fillActionBars(int) line: 350 WorkbenchWindow.fillActionBars(int) line: 3069 WorkbenchWindow.<init>(int) line: 347
This trace seems to happen once per feature plugin, for a total of 9 times in the SDK.
Based on the stack, it seems that it is trying to fetch the intro URL file. This is backward compatibility support for <3.0 Welcome support. Since we are now in 3.2, we may simply fix it by not making this check any more. I am not aware of feature still producing old Welcome content.
Jeff and I looked through this, and looks like an alternative fix is to not resolve bundle URLS into jar: URLs in the class IniFileReader. If bundle URLs are used, then we control at the OSGi level whether verification happens or not. If JAR URLs are used, you have no choice as verification happens by default. I will attach a patch that I have run some basic tests on, and it seems to fix the problem.
Created attachment 38524 [details] Patch Note I have only done minimal testing of this. It would be good for someone who is familiar with this code path to verify (we couldn't see why the URLs were being resolved, but perhaps there was some reason?)
I'm not convinced that it's essential to fix this for RC2. With the other turmoil today it might be better to wait until after we declare RC2.
On the other hand, if removing support for <3.0 Welcome buys us some startup improvement, it might be worth going with that fix instead of or in addition to my patch. We'll take any startup performance improvement we can get.
It may help, but PDE is reporting big drop in performance for plug-in resolution step. This is a more persistent problem that we should try to address in a more substantial way.
Meant to say 'pervasive'.
We have decided to pull JAR signing for Eclipse 3.2. However, we still want to get these fixes in if possible. We know that some people will want to take Eclipse 3.2 and sign it, and we will likely be putting signing back into the builds after 3.2 has shipped.
The importance of running well with signed bundles has not gone away. We have just decided that we should not, for now, force the consequences of signing on everyone at this stage in the release cycle. Fixes like this are strongly encouraged.
Can this fix be considered for RC3? Signing is still important for many people in the community, even though we are not signing 3.2 ourselves. If the fix works it improves startup performance in the signed JAR case, it's worth getting this in for 3.2.
(In reply to comment #11) > If the fix > works it improves startup performance in the signed JAR case, it's worth > getting this in for 3.2. John, I am a bit concerned about the comment 'if the fix works'. At this stage, I would assume that patches for such a sensitive code (update configurator) have been unit tested before proposing.
I don't know the code well enough to be confident that my patch is the best fix... I was hoping someone who knows that code could comment on it. I tested it to the extent that I started Eclipse with the patch running, I stepped through the code in the debugger to be sure that it was being executed, and no problems occurred. However, I don't have any context on what this code is doing, what the expected behaviour is, etc... if it is a code path for pre-3.0 welcome, perhaps a plugin that uses pre-3.0 welcome needs to be installed to properly test it?
What's up here?
RC3 candidate - Branko, please check if there are any side effects when running 3.2 tests with this.
Released.
Need formal votes. Dejan adds +1.
Jeff, need additional +1 before releasing.
Wassim, you can help Jeff to unblock this backlog. This bug is checked and ready to go.
+1 for RC3
fixed
