Proposal: Fully Concurrent ClassLoading (original) (raw)

David M. Lloyd david.lloyd at redhat.com
Tue Dec 11 15:10:29 UTC 2012

No problem. What do you mean by "instrumentation"?

On 12/10/2012 11:18 PM, David Holmes wrote:

David,

Many thanks for trialling this so promptly! Do you have any suggestions for what instrumentation you would like to see accompany this? David On 11/12/2012 1:41 PM, David M. Lloyd wrote: 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: http://cr.openjdk.java.net/~dholmes/concurrent-loaders/webrev.hotspot/ http://cr.openjdk.java.net/~dholmes/concurrent-loaders/webrev.jdk/ 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 happened). On our class loader implementations, I'm initializing this way: static { try { ClassLoader.registerAsFullyConcurrent(); } catch (Throwable ignored) { try { ClassLoader.registerAsParallelCapable(); } 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