Hi All, I have updated the patch[3] to reflect all of your suggestions.
[3] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.02/ Thanks a lot! 2014-12-05 10:39 GMT+08:00 deven you <ydwch...@gmail.com>: > Hi Alan, > > I am not clear whether canonicalization cache enabled or disabled, however > I think even the cache is enable, it may not help much for the start up > stage especially if the app uses many different files. > > The cache should speed up applications for common case especially after > start up and this patch will specifically solve the problem for > FilePermssion. > > I will update the patch soon with your suggestion and Wenjian's. > > Thanks a lot! > > > > 2014-12-01 20:50 GMT+08:00 Alan Bateman <alan.bate...@oracle.com>: > >> On 01/12/2014 08:06, deven you wrote: >> >>> Hi All, >>> File.getCanonicalPath() is a very time-consuming method, we observed >>> significant performance degradation from some application's startup stage >>> with java.io.FilePermission. However, lazying load the calls to >>> getCanonicalPath() from java.ioFilePermission is straightforward and >>> solve >>> this problem effectively. Openjdk bug[1] tracks this bug and here is the >>> patch [2]. Could anyone take a look? >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8066211 >>> [2] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.00/ >>> >> >> Do you run with canonicalization cache enabled or disabled? While I don't >> agree with this cache, it seem to mostly eliminate complaints in this area >> after it was added (in JDK 1.4 I think). >> >> As regards the patch then it is a bit ugly. Could you use cpath == null >> instead of introducing a flag? If a flag is required then I think it will >> need a better name. Also if init is split then it might be cleaner to have >> initMask and initCanonicalPath. >> >> -Alan >> >> >> >
