RFR (XS): 8140683: Deduplicate Strings in UnixFileSystem canonical caches

[Claes Redestad]

On 2015-11-03 14:19, Paul Sandoz wrote:
>> On 28 Oct 2015, at 21:01, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> Hi,
>>
>> while investigating startup and footprint for jigsaw, I found this unrelated oddity where java.io.UnixFileSystem is missing an opportunity to deduplicate file paths determined to be equal when putting them into its internal cache. Also avoid some recalculation of paths determined to be canonical for no good reason and we're golden:
>>
>> webrev: http://cr.openjdk.java.net/~redestad/8140683/webrev.01
>> bug: https://bugs.openjdk.java.net/browse/JDK-8140683
>>
> I am not an expert in this area, but something does not feel right that you have modified things so the the key and value for a cache entry are the same. Why bother caching in that is the case? I am missing something obvious here?
>
> Paul.

The caching is only done to avoid possibly expensive calls into 
canonicalize0, and I've not been able to construct a case where the key 
and the value aren't equal to begin with (in the second case it's an 
invariant since we already verified resDir.equals(dir), in the first 
case it follows from how parentOrNull is implemented), thus I'm 
convinced that this patch doesn't currently change semantics (there's 
even that primordial comment that the java.home prefix cache could just 
as easily be considered a set, but java.io.ExpiringCache is what it is).

/Claes