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
