Bug ID: JDK-8057936 java.net.URLClassLoader.findClass uses exceptions in control flow

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 8	JDK 9
8u40Fixed	9 b31Fixed

If one runs a classloader benchmark: 
  http://cr.openjdk.java.net/~shade/8053904/benchmarks.jar 

...with Nashorn-generated class files: 
 http://cr.openjdk.java.net/~shade/8053904/classes.jar 

...and jdk9 executed as: 
 $ java -jar benchmarks.jar -wi 0 -i 30 -r 10s -p file=classes.jar 

...one can produce this profile: 
 http://cr.openjdk.java.net/~shade/8053904/class-install-calltree-java-2.txt

Looking closely at this profile, one can note a low-hanging fruit: exceptions are frequent. The call tree shows where the exceptions are instantiated. Another view in the profiler shows that a significant amount of time is spend in constructing the stack traces:
 6.670	java.lang.Throwable.fillInStackTrace(int)

That's 6.6 seconds of total 313 secs of run (around ~2%).
I think we need to stop doing exceptions there, or at least throw the stackless exceptions.

CNFE is thrown by the extension class loader for any class to be loaded by the application class loader (i.e. the class is in the classpath). If the parent is null, there is already an optimization that it calls JVM_FindClassFromBootLoader that returns NULL if class not found instead of throwing CNFE (i.e. calling SystemDictionary::resolve_or_null)
11-09-2014
Yes, there are some paths where the callee doesn't seem to care about the CNF where a stackless or even exception free path would make sense, but without rewriting the world this optimization idea will have to be dropped for now (this was a prototype to examine the total overhead). Avoiding raising the PrivilegedActionException should net about half the measured benefit with minimal risk. I'll run some tests and prepare a patch for review.
09-09-2014
No objection although I think stackless CNF needs consideration if it make some cases harder to diagnose.
09-09-2014
Since the thing Alan mentioned only targets JDK 9, can we commit Claes' tiny patch in JDK 9, and backport it to JDK 8?
09-09-2014
Using attached prototype patch and Aleksey's benchmark I get consistently better results. Score Score error Units baseline: 1.364 0.082 s/op with patch: 1.252 0.066 s/op Turning off class verification to exaggerate effect: -noverify baseline 0.678 0.027 s/op -noverify target 0.603 0.026 s/op
09-09-2014
Would that be something that will be backportable or part of the jigsaw modular image work?
09-09-2014
Nice to know. I think Claes Redestad (watching now) can assist with performance evaluation.
09-09-2014
There are changes in the works to use a local package map that should help avoid delegation and exceptions in the system and extension class loaders.
09-09-2014

Relates :	JDK-8061244 - Use of stack-less ClassNotFoundException thrown from (URL)ClassLoader.findClass()
Relates :	JDK-8053904 - JVM Warmup: Investigate class installation overhead
Relates :	JDK-8055854 - Examine overhead in java.net.URLClassLoader