JDK-8057936 : java.net.URLClassLoader.findClass uses exceptions in control flow
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.net
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-09-09
  • Updated: 2016-05-27
  • Resolved: 2014-09-11
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.
8u40Fixed 9 b31Fixed
Related Reports
Relates :  
Relates :  
Relates :  
If one runs a classloader benchmark: 

...with Nashorn-generated class files: 

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

...one can produce this profile: 

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)

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.

No objection although I think stackless CNF needs consideration if it make some cases harder to diagnose.

Since the thing Alan mentioned only targets JDK 9, can we commit Claes' tiny patch in JDK 9, and backport it to JDK 8?

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

Would that be something that will be backportable or part of the jigsaw modular image work?

Nice to know. I think Claes Redestad (watching now) can assist with performance evaluation.

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.