Hi Mandy,
Thanks for taking a look. I've wondered myself that now it might not be
the right time to change things in ClassLoader(s) as greater changes are
pending. Perhaps we can revisit this after they are over if it still
matters then.
Regards, Peter
On 10/23/2014 12:42 AM, Mandy Chung wrote:
Hi Peter,
On 10/21/2014 3:37 AM, Peter Levart wrote:
http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoader.CNFE/webrev.03/
I skimmed through this webrev. I would suggest to hold off this
patch and there are various ideas of the optimization for class
loading performance with modules.
Throwing CNFE attributes to one part of the class loading cost that
hasn't proven to be significant in real-world applications. Recently I
have instrumented the class loading code to add more fine-grained
performance counters to determine the overhead of CNFE with and
without stacktrace and again the applications I used to measure shows
the CNFE stack trace isn't the focus. A class lookup cost would
depend on the class loader hierarchy, the search path of each class
loader and what classes are being looked up from a class loader. The
cost of looking up a class local in the class loader's search path
involves the parent delegation lookup time + CNFE + findClass (lookup
class in its local search path). In a typical real-world application,
the parent delegation lookup time would be much significant than
CNFE. CNFE is thrown by loadClass for class lookup that is one
typical suspect for class loading performance issue. On the other
hand, resource lookup actually has the parent delegation performance
cost in which CNFE is not involved.
With modules, this would give the opportunity to consider skipping
parent delegation, direct class lookup when the class is known to be
local. That'd avoid CNFE creation completely.
Talking about exceptions and fillInStackTrace, it's known to be
significant cost. It'd be interesting to have the VM flag that can
measure the time it spends in filling in the backtrace of each
exception type (and perhaps the mean and max stack depth) that will
give a better idea of the performance distribution. In addition,
doPrivileged wraps checked exception with PrivilegedActionException
that essentially has the same stack trace and it doubles the cost even
in the absence of security manager. I have exchanged some mail with
the security team to see if this is a low-hanging fruit to improve the
performance.
Mandy
