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

Peter Levart peter.levart at gmail.com
Tue Oct 21 14:47:49 UTC 2014


On 10/21/2014 12:37 PM, Peter Levart wrote:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoader.CNFE/CLBench2.java 
>
>

Just an observation...

Running this benchmark for about a minute in sampling profiler for small 
call-stack depth (calling loadClass() public method on XLoader directly 
from main method), using original JDK code reveals that:

22.9% of CPU time is spent in findLoadedClass0[native] method called on 
XLoader
33.0% of CPU time is spent in defineClass1[native] method called on XLoader
16.7% of CPU time is spent in findLoadedClass0[native] method called on 
ExtClassLoader
23.6% of CPU time is spent in findBootstrapClass[native] static method 
called from ExtClassLoader
3.8% of CPU time is spent elsewhere (1.6% of that in 
Throwable.fillInStackTrace - not much because of minimal call-stack depth)

Profiling patched code (stack-less CNFE + findLoadedClass() avoidance) 
reveals the following distribution of CPU time:

65.9% of CPU time is spent in defineClass1[native] method called on XLoader
32.2% of CPU time is spent in findBootstrapClass[native] static method 
called from ExtClassLoader
1.9 % of CPU time is spent elsewhere (1.7% of that for doPrivileged calls)


Since findLoadedClass0[native] calls are non-existent in this benchmark 
on patched code and since they consume about 39.6% CPU time on original 
code, one could conclude that patched code benchmark results should show 
about 40% improvement in execution speed compared to original code 
benchmark. They show only 10% improvement (with minimal call-stack 
depth). The reason seems to be that defineClass1[native] method and 
findBootstrapClass[native] method consume absolutely more time when 
findLoadedClass() is not called - there seems to be some kind of 
"slot-reservation" in system dictionary going on in findLoadedClass() 
that prepares the sceen for findBootstrapClass/defineClass so that they 
can execute faster afterwards. But the overall effect still seems to be 
improvement in execution speed when findLoadedClass is skipped.

Peter




More information about the core-libs-dev mailing list