RFR: 8061244 Use of stack-less ClassNotFoundException thrown from (URL)ClassLoader.findClass()
Peter Levart
peter.levart at gmail.com
Tue Oct 21 10:37:20 UTC 2014
Hi,
I guess we are not happy with stack-traces that only reveal call stack
up to the public ClassLoader.loadClass() method and hide everything
happening after that even if paired with a more descriptive message. So
I improved the strategy of throwing stack-less exception. New strategy
throws full-stack exception from findClass() if findClass() is invoked
on the "initiating" class loader and stack-less exception otherwise. How
can we know if a particular ClassLoader instance is the initiating class
loader for a particular class loading request? VM knows that when
invoking Class.forName() or when VM triggers class loading, because such
calls are wired through VM or initiate from VM. On the Java side, we can
establish a similar thread-local context at the entry point of
Class.loadClass() public method.
This strategy gives normal stack traces for exceptions that escape the
ClassLoader.loadClass() public method and avoids creating stack-full
exceptions that are later swallowed.
That's not all. I have another optimization at hand. Parallel capable
class loaders maintain a ConcurrentHashMap of Objects used as locks to
synchronize on when executing class loading request for a particular
class name. These seem like a waste of resource and can be used for more
than just locks. My 1st attempt at (ab)using these objects is the following:
http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoader.CNFE/webrev.03/
Here a boolean flag is added to such Lock object that indicates whether
a class loading attempt has already been performed for a particular
class name. The 1st attempt at loading a particular class can therefore
skip calling findLoadedClass() native method. This has a measurable
performance impact as indicated in the following benchmark:
http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoader.CNFE/CLBench2.java
This is a variant of previous benchmark - only the part that measures
successful attempts at loading a class with a child of extension class
loader, but does that at different call-stack depths (10, 20, 40, 80,
160 frames). Original JDK 9 code gives these results:
Benchmark Mode Samples Score Error Units
j.t.CLBench2.loadNewClassSuccessSS010 ss 5 3.947 ± 0.080 s
j.t.CLBench2.loadNewClassSuccessSS020 ss 5 4.001 ± 0.119 s
j.t.CLBench2.loadNewClassSuccessSS040 ss 5 4.068 ± 0.115 s
j.t.CLBench2.loadNewClassSuccessSS080 ss 5 4.323 ± 0.061 s
j.t.CLBench2.loadNewClassSuccessSS160 ss 5 4.633 ± 0.118 s
Doing stack-less CNF exceptions shows that call-stack depth does not
have an impact any more:
Benchmark Mode Samples Score Error Units
j.t.CLBench2.loadNewClassSuccessSS010 ss 5 3.753 ± 0.155 s
j.t.CLBench2.loadNewClassSuccessSS020 ss 5 3.755 ± 0.160 s
j.t.CLBench2.loadNewClassSuccessSS040 ss 5 3.767 ± 0.124 s
j.t.CLBench2.loadNewClassSuccessSS080 ss 5 3.762 ± 0.148 s
j.t.CLBench2.loadNewClassSuccessSS160 ss 5 3.781 ± 0.146 s
Adding findLoadedClass() avoidance on top of that gives even better results:
Benchmark Mode Samples Score Error Units
j.t.CLBench2.loadNewClassSuccessSS010 ss 5 3.539 ± 0.185 s
j.t.CLBench2.loadNewClassSuccessSS020 ss 5 3.548 ± 0.165 s
j.t.CLBench2.loadNewClassSuccessSS040 ss 5 3.586 ± 0.226 s
j.t.CLBench2.loadNewClassSuccessSS080 ss 5 3.541 ± 0.053 s
j.t.CLBench2.loadNewClassSuccessSS160 ss 5 3.570 ± 0.113 s
Regards, Peter
On 10/16/2014 04:05 PM, Peter Levart wrote:
> I created an issue in Jira to track this investigation:
>
> https://bugs.openjdk.java.net/browse/JDK-8061244
>
> The latest webrev of proposed patch is still:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoader.CNFE/webrev.02/
>
> I invite the public to review it.
>
> Thanks.
>
> Peter
>
> On 10/16/2014 10:44 AM, Peter Levart wrote:
>> Hi,
>>
>> As for usage of SharedSecrets, they are not needed to access CNFE
>> package-private constructor from java.lang.ClassLoader, since they
>> are in the same package, and from java.net.URLClassLoader, the call
>> to super.findClass(name) does the job. So here's an updated webrev
>> that also includes more descriptive message:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoader.CNFE/webrev.02/
>>
>>
>> Regards, Peter
>>
>> On 10/16/2014 09:35 AM, Peter Levart wrote:
>>> On 10/16/2014 01:49 AM, Stanimir Simeonoff wrote:
>>>> First, really nice tests.
>>>>
>>>> As for hiding: missing the real classloader impl. might be quite a
>>>> bumper
>>>> for some middleware implementations. That would make pretty hard to
>>>> trace
>>>> dependency issues without explicit logging, the latter is usually
>>>> available
>>>> but still. Also it'd depend if the classloaders actually use
>>>> super.findClass() or not.
>>>> IMO, the option should be switchable via some system property.
>>>
>>> With a little tweak, the message of the stack-less exception thrown
>>> from findClass() methods can be extended to include the
>>> classloader's runtime class name and this message can be inherited
>>> by a replacement stack-full exception. So the stack-trace would look
>>> like:
>>>
>>> Exception in thread "main" java.lang.ClassNotFoundException: XXX
>>> (thrown by: sun.misc.Launcher$AppClassLoader)
>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:366)
>>> at java.lang.Class.forName0(Native Method)
>>> at java.lang.Class.forName(Class.java:265)
>>> at Test.doIt(Test.java:7)
>>> at Test.main(Test.java:11)
>>>
>>> Instead of what we have now:
>>>
>>> Exception in thread "main" java.lang.ClassNotFoundException: XXX
>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:426)
>>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:317)
>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:359)
>>> at java.lang.Class.forName0(Native Method)
>>> at java.lang.Class.forName(Class.java:265)
>>> at Test.doIt(Test.java:7)
>>> at Test.main(Test.java:11)
>>>
>>>
>>> Would this be enough to cover your concern?
>>>
>>> Regards, Peter
>>>
>>>>
>>>> I am not sure about the need to hide the stackless c-tor as the
>>>> effect can
>>>> be achieved by overriding fillInStackTrace(); w/o the extra baggage of
>>>> JavaLangAccess.
>>>>
>>>> Overall very decent improvement.
>>>>
>>>> Cheers
>>>> Stanimir
>>>>
>>>>
>>
>
More information about the core-libs-dev
mailing list