Hi,
Can you elaborate more on the performance degradation that you are
seeing at startup? Are you seeing this when you are running with or
without a SecurityManager? If without a SecurityManager, can you provide
some code paths/examples? As far as I can see, with the proposed fix you
are moving the performance hit to runtime, and it will be triggered the
first time a FilePermission check is made, and at worst case it may need
to canonicalize all the FilePermissions in the FilePermissionCollection.
Also, with the latest proposed fix you are potentially making
performance worse by introducing synchronized blocks (which as Peter
noted, still have some race conditions). I can understand why you want
to improve application startup, but I want to make sure I understand the
use case(s) a little better first.
Thanks,
Sean
On 12/01/2014 03:06 AM, 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/
