Proposal: Fully Concurrent ClassLoading

David M. Lloyd david.lloyd at
Tue Dec 11 03:41:45 UTC 2012

On 12/10/2012 06:36 PM, David Holmes wrote:
> On 10/12/2012 11:53 PM, David M. Lloyd wrote:
>> On 12/09/2012 10:03 PM, David Holmes wrote:
>>> That sounds promising. Are you in a position to try out this proposal on
>>> a testbed with your app server?
>> Sure, I'd love to. What tree should I build?
> Please apply the patches from the webrevs here:
> They should apply to a jdk8 or tl forest. (And I hope I didn't mess
> something up generating the webrev ;-) )

Well, I've just gotten everything working and done some cursory testing 
on a startup of an "empty" JBoss AS 7 instance, and then reviewing the 
metrics reported by our class loader.  Our timing metrics are not really 
great for general-purpose benchmarking (for various uninteresting 
reasons), but I can at least get enough information to know everything 
is working more or less as expected:

On JDK 6 with our "unsafe" lockless modification, we're typically 
loading 4707 classes, and I'm seeing anywhere from 0 to 5 define races 
that were automatically resolved.

On JDK 7 using the standard registerAsParallelCapable() mechanism, we 
are loading 4711 classes and I'm seeing 35-50 define races that were 
automatically resolved - the overhead of locking starts to come to the 
fore I think.

On JDK 8 with your patches, we are loading around 4750 classes and there 
are, as expected, 0 define races (I believe, however, that we're getting 
a false count though whenever defineClass() returns an already-defined 
class - it would be nice if there were *some* way to detect that this 

On our class loader implementations, I'm initializing this way:

     static {
         try {
         } catch (Throwable ignored) {
             try {
             } catch (Throwable ignored2) {

The debugging message confirms that our class loaders are successfully 
registered as fully concurrent, and the fact that it doesn't hang or 
crash on JDK 7 indicates that they are still properly being registered 
as parallel-capable on that platform.


More information about the core-libs-dev mailing list