Community
Participate
Working Groups
The invalid archive cache is now evicted too infrequently. Since jars can come from network drives and be subject to transient I/O errors, it should be cleared on every build. As it stands now, the previously invalid jar will only get reevaluated if its timestamp changes or if the classpath is modified.
Sent up for review: https://git.eclipse.org/r/38155
For the records, this is done for a full build, right? Actually, I would like to know how frequently people run into this. In my development environment I have never seen this, of course, because it's all part of the eclipse installation.
(In reply to Jay Arthanareeswaran from comment #2) > For the records, this is done for a full build, right? > > Actually, I would like to know how frequently people run into this. In my > development environment I have never seen this, of course, because it's all > part of the eclipse installation. Steps or even a test case would be good.
Created attachment 250797 [details] invalidArchivesCache marking org.eclipse.core.runtime as invalid
(In reply to Dani Megert from comment #3) > (In reply to Jay Arthanareeswaran from comment #2) > > For the records, this is done for a full build, right? > > > > Actually, I would like to know how frequently people run into this. In my > > development environment I have never seen this, of course, because it's all > > part of the eclipse installation. > > Steps or even a test case would be good. Since items only get added to the invalid archive cache due to I/O erorrs, steps to reproduce are tough, but I fabricated a way. You can take the attached invalidArchivesCache file, which declares the org.eclipse.core.runtime* jars as invalid, and drop it in your workspace's .metadata/.plugins/org.eclipse.jdt.core directory before starting Eclipse. In the jdt.core project open JavaCore.java and see that the Platform and Plugin types are now unknown to the reconciler. Currently the only way to get these values evicted from the cache are to: 1) Change the classpath, by doing something like going into the Java Build Path preferences and reordering the plug-in's access rules. 2) Change the timestamp on a jar, which results in a JavaProject.resetResolvedClasspath, which clears all JavaModelManager caches. These two ways to evict from the cache aren't sufficient if files got added to the cache due to transient I/O errors. My first patch was based on misinterpreting the red squigglies in the editor as compilation issues, but they are actually coming from the reconciler. So my first patch is bad. I propose instead keeping a timestamp for every path that is added to the invalid archives cache, and on each access to the cache, evicting the path if "N" seconds have elapsed since the path was added. Thoughts? BTW, there is a second issue here, in that even evicting items from the cache doesn't tickle the reconciler to resolve the imports of types from those jar files. After clearing out the invalid archive cache I expected closing and reopening the editor would resolve the imports, but the reconciler seems to be caching additonal state and only restarting Eclipse helped.
(In reply to Terry Parker from comment #5) > BTW, there is a second issue here, in that even evicting items from the > cache doesn't tickle the reconciler to resolve the imports of types from > those jar files. After clearing out the invalid archive cache I expected > closing and reopening the editor would resolve the imports, but the > reconciler seems to be caching additonal state and only restarting Eclipse > helped. Sounds like the JavaModelCache might hold some JavaModelCache.NON_EXISTING_JAR_TYPE_INFO in its jarTypeCache? That would raise the question how to find those entries in jarTypeCache (indexed by IType) that correspond to a jar that's being updated from invalid to valid? Not sure if updating is supposed to be happening eagerly (when the jar is validated) or lazily (when the IType is accessed for its info).
(In reply to Stephan Herrmann from comment #6) > (In reply to Terry Parker from comment #5) > > BTW, there is a second issue here, in that even evicting items from the > > cache doesn't tickle the reconciler to resolve the imports of types from > > those jar files. After clearing out the invalid archive cache I expected > > closing and reopening the editor would resolve the imports, but the > > reconciler seems to be caching additonal state and only restarting Eclipse > > helped. > > Sounds like the JavaModelCache might hold some > JavaModelCache.NON_EXISTING_JAR_TYPE_INFO in its jarTypeCache? > That would raise the question how to find those entries in jarTypeCache > (indexed by IType) that correspond to a jar that's being updated from > invalid to valid? > Not sure if updating is supposed to be happening eagerly (when the jar is > validated) or lazily (when the IType is accessed for its info). I abandoned the original patch. The issue here is similar to bug 162621 "Validation errors do not clear after replacing jar file". That fix updated the DeltaProcessor to clear JavaProjectElementInfo caches on changes to the timestamp/size of a jar. In this case, transient IO errors cause both the JavaProjectElementInfo and invalid archive caches get initialized with invalid jars. Re-reading those jars will succeed, but the invalid archive cache prevents the attempt from being made. The invalid archive cache only evicts items during classpath validations, which are mainly triggered by classpath updates. Even when the invalid archive paths are evicted from the cache, the JavaProjectElementInfo caches hold stale data. Since the timestamps and sizes of the “initially invalid” jars don’t change, the fix for bug 162621 doesn’t kick in. The result of these stale caches is that name lookups for symbols in these jars continue to fail, even though the jars are readable. We propose using time-based eviction of the entries in the invalid archive cache, and clearing the JavaProjectElementInfo caches for affected projects when an item is seen to transition from invalid to valid.
New Gerrit change created: https://git.eclipse.org/r/44153
(In reply to Terry Parker from comment #7) > We propose using time-based eviction of the entries in the invalid archive > cache, and clearing the JavaProjectElementInfo caches for affected projects > when an item is seen to transition from invalid to valid. For the records, the patch no longer saves and reloads the invalid archive cache on exit and start respectively, which is okay for me.
Directly released in master: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=9359ba8e380aaa366dda637da6a8c80a24875b62 Thanks Terry for the contribution.
Verified for 4.5 M7 with build I20150426-2000.
