RFR: 8061244 Use of stack-less ClassNotFoundException thrown from (URL)ClassLoader.findClass()

Mandy Chung mandy.chung at oracle.com
Wed Oct 22 22:42:22 UTC 2014

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 

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.


More information about the core-libs-dev mailing list