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

[Peter Levart]

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