[MRESOLVER-68] Add caching around File.getCanonicalPath

[jira-importer]

Richard Atkins opened MRESOLVER-68 and commented

Maven Resolver spends a lot of time calculating the canonical path for a File, and subsequently interning the result, in order to generate an in memory lock object for the File. This can add up to 50% or more of the time in a build, especially when using maven-enforcer-plugin with the bannedDependencies rule with searchTransitive true.

Caching these lookups will reduce build times, even for well behaved plugins.

---

Issue Links:

• MRESOLVER-132 Remove synchronization in TrackingFileManager
  ("is superceded by")

Remote Links:

• GitHub Pull Request #29
  

[jira-importer]

Michael Osipov commented

I think that this ticket is not required because no the canonicalization necessary. The TrackingFileManager is package private, thus never used externally. It uses the interned string reperesentation of the canonical path and file locking. We all know that file locking in a single JVM are pointless, it will lead to race conditions. This is why the locking is multistage. Single JVM and file locks for multi JVM. The interesting part is that if you look up the call stack of  TrackingFileManager#read(File) and TrackingFileManager#update(File, Map<String, String>) you'll see that all of them are wrapped in a SyncContext which already add locks for them. I don't understand why this is done here. If outer lock works, I see no need to lock again somewhere deeper. I am also keen to say that this kind of synchronization can be completely removed if you have a decent SyncContextFactory implementation.
 I am inclined to override the TrackingFileManager with MRESOLVER-130 for obvious reasons.
Elliotte Rusty Harold, please add your thoughts on my analysis.